Author Archives: Camille

Testing and Testing (One of them is a Fake).

 Hello!

This week in class we’ve been discussing testing using fakes, more specifically with Stubs. Our first assignment this week told us about the different kinds of fakes used in testing, which I found a little confusing at first, since I would have liked to have seen a more literal example of all the different variants. That is why, for the sake of improving my knowledge on the subject going forward, since this is something we’ll be talking about, I decided to do some reading on stubs and mocks, from a blog post written by Raphael F. on Medium. 

The article spoke at length about the differences between mocks and stubs, and gave some meaningful examples of both. I appreciated the use of diagrams in the article, as it shows what each of them interacts with and how (i.e. A stub doesn’t interact with a database, and is instead a hard-coded value to be grabbed for testing). That wasn’t something that was immediately obvious to me in the assignments, and during our assignment on Stubs specifically it began to make more sense, but I appreciate the way the article laid out the concept in plain text, and made it easier to understand. I also liked that the blog post went over real world applications for each of the fake types, such a using stubs for read/write actions to keep the code and files separate, or using mocks for API testing. Admittedly I am still a little hazy on mocks, but I think by the time we go over it in class, it will all make sense.

 In closing, I really do value stubs as valuable pieces of testing equipment, since they allow me to test code without having to have every intricate detail finished. It makes sense for confirming methods got used, and that a specific path through the program is being followed. Stubs can’t do everything, you can’t really test complex operations on a piece of code that doesn’t work, but for basic probing and testing, I could see myself using stubs a lot more often. It feels like one of those things that I could have used before without thinking about it, which makes sense, as I am the kind of programmer who likes taking things one step at a time, and making sure one piece works before moving on to the next. But now that I have a name connected to the action, I really appreciate it as a tool that will play a big role in my programming career going forward.

 

 Link to the blog post in question: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Testing and Testing (One of them is a Fake).

 Hello!

This week in class we’ve been discussing testing using fakes, more specifically with Stubs. Our first assignment this week told us about the different kinds of fakes used in testing, which I found a little confusing at first, since I would have liked to have seen a more literal example of all the different variants. That is why, for the sake of improving my knowledge on the subject going forward, since this is something we’ll be talking about, I decided to do some reading on stubs and mocks, from a blog post written by Raphael F. on Medium. 

The article spoke at length about the differences between mocks and stubs, and gave some meaningful examples of both. I appreciated the use of diagrams in the article, as it shows what each of them interacts with and how (i.e. A stub doesn’t interact with a database, and is instead a hard-coded value to be grabbed for testing). That wasn’t something that was immediately obvious to me in the assignments, and during our assignment on Stubs specifically it began to make more sense, but I appreciate the way the article laid out the concept in plain text, and made it easier to understand. I also liked that the blog post went over real world applications for each of the fake types, such a using stubs for read/write actions to keep the code and files separate, or using mocks for API testing. Admittedly I am still a little hazy on mocks, but I think by the time we go over it in class, it will all make sense.

 In closing, I really do value stubs as valuable pieces of testing equipment, since they allow me to test code without having to have every intricate detail finished. It makes sense for confirming methods got used, and that a specific path through the program is being followed. Stubs can’t do everything, you can’t really test complex operations on a piece of code that doesn’t work, but for basic probing and testing, I could see myself using stubs a lot more often. It feels like one of those things that I could have used before without thinking about it, which makes sense, as I am the kind of programmer who likes taking things one step at a time, and making sure one piece works before moving on to the next. But now that I have a name connected to the action, I really appreciate it as a tool that will play a big role in my programming career going forward.

 

 Link to the blog post in question: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Testing and Testing (One of them is a Fake).

 Hello!

This week in class we’ve been discussing testing using fakes, more specifically with Stubs. Our first assignment this week told us about the different kinds of fakes used in testing, which I found a little confusing at first, since I would have liked to have seen a more literal example of all the different variants. That is why, for the sake of improving my knowledge on the subject going forward, since this is something we’ll be talking about, I decided to do some reading on stubs and mocks, from a blog post written by Raphael F. on Medium. 

The article spoke at length about the differences between mocks and stubs, and gave some meaningful examples of both. I appreciated the use of diagrams in the article, as it shows what each of them interacts with and how (i.e. A stub doesn’t interact with a database, and is instead a hard-coded value to be grabbed for testing). That wasn’t something that was immediately obvious to me in the assignments, and during our assignment on Stubs specifically it began to make more sense, but I appreciate the way the article laid out the concept in plain text, and made it easier to understand. I also liked that the blog post went over real world applications for each of the fake types, such a using stubs for read/write actions to keep the code and files separate, or using mocks for API testing. Admittedly I am still a little hazy on mocks, but I think by the time we go over it in class, it will all make sense.

 In closing, I really do value stubs as valuable pieces of testing equipment, since they allow me to test code without having to have every intricate detail finished. It makes sense for confirming methods got used, and that a specific path through the program is being followed. Stubs can’t do everything, you can’t really test complex operations on a piece of code that doesn’t work, but for basic probing and testing, I could see myself using stubs a lot more often. It feels like one of those things that I could have used before without thinking about it, which makes sense, as I am the kind of programmer who likes taking things one step at a time, and making sure one piece works before moving on to the next. But now that I have a name connected to the action, I really appreciate it as a tool that will play a big role in my programming career going forward.

 

 Link to the blog post in question: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Testing and Testing (One of them is a Fake).

 Hello!

This week in class we’ve been discussing testing using fakes, more specifically with Stubs. Our first assignment this week told us about the different kinds of fakes used in testing, which I found a little confusing at first, since I would have liked to have seen a more literal example of all the different variants. That is why, for the sake of improving my knowledge on the subject going forward, since this is something we’ll be talking about, I decided to do some reading on stubs and mocks, from a blog post written by Raphael F. on Medium. 

The article spoke at length about the differences between mocks and stubs, and gave some meaningful examples of both. I appreciated the use of diagrams in the article, as it shows what each of them interacts with and how (i.e. A stub doesn’t interact with a database, and is instead a hard-coded value to be grabbed for testing). That wasn’t something that was immediately obvious to me in the assignments, and during our assignment on Stubs specifically it began to make more sense, but I appreciate the way the article laid out the concept in plain text, and made it easier to understand. I also liked that the blog post went over real world applications for each of the fake types, such a using stubs for read/write actions to keep the code and files separate, or using mocks for API testing. Admittedly I am still a little hazy on mocks, but I think by the time we go over it in class, it will all make sense.

 In closing, I really do value stubs as valuable pieces of testing equipment, since they allow me to test code without having to have every intricate detail finished. It makes sense for confirming methods got used, and that a specific path through the program is being followed. Stubs can’t do everything, you can’t really test complex operations on a piece of code that doesn’t work, but for basic probing and testing, I could see myself using stubs a lot more often. It feels like one of those things that I could have used before without thinking about it, which makes sense, as I am the kind of programmer who likes taking things one step at a time, and making sure one piece works before moving on to the next. But now that I have a name connected to the action, I really appreciate it as a tool that will play a big role in my programming career going forward.

 

 Link to the blog post in question: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Testing and Testing (One of them is a Fake).

 Hello!

This week in class we’ve been discussing testing using fakes, more specifically with Stubs. Our first assignment this week told us about the different kinds of fakes used in testing, which I found a little confusing at first, since I would have liked to have seen a more literal example of all the different variants. That is why, for the sake of improving my knowledge on the subject going forward, since this is something we’ll be talking about, I decided to do some reading on stubs and mocks, from a blog post written by Raphael F. on Medium. 

The article spoke at length about the differences between mocks and stubs, and gave some meaningful examples of both. I appreciated the use of diagrams in the article, as it shows what each of them interacts with and how (i.e. A stub doesn’t interact with a database, and is instead a hard-coded value to be grabbed for testing). That wasn’t something that was immediately obvious to me in the assignments, and during our assignment on Stubs specifically it began to make more sense, but I appreciate the way the article laid out the concept in plain text, and made it easier to understand. I also liked that the blog post went over real world applications for each of the fake types, such a using stubs for read/write actions to keep the code and files separate, or using mocks for API testing. Admittedly I am still a little hazy on mocks, but I think by the time we go over it in class, it will all make sense.

 In closing, I really do value stubs as valuable pieces of testing equipment, since they allow me to test code without having to have every intricate detail finished. It makes sense for confirming methods got used, and that a specific path through the program is being followed. Stubs can’t do everything, you can’t really test complex operations on a piece of code that doesn’t work, but for basic probing and testing, I could see myself using stubs a lot more often. It feels like one of those things that I could have used before without thinking about it, which makes sense, as I am the kind of programmer who likes taking things one step at a time, and making sure one piece works before moving on to the next. But now that I have a name connected to the action, I really appreciate it as a tool that will play a big role in my programming career going forward.

 

 Link to the blog post in question: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Testing and Testing (One of them is a Fake).

 Hello!

This week in class we’ve been discussing testing using fakes, more specifically with Stubs. Our first assignment this week told us about the different kinds of fakes used in testing, which I found a little confusing at first, since I would have liked to have seen a more literal example of all the different variants. That is why, for the sake of improving my knowledge on the subject going forward, since this is something we’ll be talking about, I decided to do some reading on stubs and mocks, from a blog post written by Raphael F. on Medium. 

The article spoke at length about the differences between mocks and stubs, and gave some meaningful examples of both. I appreciated the use of diagrams in the article, as it shows what each of them interacts with and how (i.e. A stub doesn’t interact with a database, and is instead a hard-coded value to be grabbed for testing). That wasn’t something that was immediately obvious to me in the assignments, and during our assignment on Stubs specifically it began to make more sense, but I appreciate the way the article laid out the concept in plain text, and made it easier to understand. I also liked that the blog post went over real world applications for each of the fake types, such a using stubs for read/write actions to keep the code and files separate, or using mocks for API testing. Admittedly I am still a little hazy on mocks, but I think by the time we go over it in class, it will all make sense.

 In closing, I really do value stubs as valuable pieces of testing equipment, since they allow me to test code without having to have every intricate detail finished. It makes sense for confirming methods got used, and that a specific path through the program is being followed. Stubs can’t do everything, you can’t really test complex operations on a piece of code that doesn’t work, but for basic probing and testing, I could see myself using stubs a lot more often. It feels like one of those things that I could have used before without thinking about it, which makes sense, as I am the kind of programmer who likes taking things one step at a time, and making sure one piece works before moving on to the next. But now that I have a name connected to the action, I really appreciate it as a tool that will play a big role in my programming career going forward.

 

 Link to the blog post in question: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Testing and Testing (One of them is a Fake).

 Hello!

This week in class we’ve been discussing testing using fakes, more specifically with Stubs. Our first assignment this week told us about the different kinds of fakes used in testing, which I found a little confusing at first, since I would have liked to have seen a more literal example of all the different variants. That is why, for the sake of improving my knowledge on the subject going forward, since this is something we’ll be talking about, I decided to do some reading on stubs and mocks, from a blog post written by Raphael F. on Medium. 

The article spoke at length about the differences between mocks and stubs, and gave some meaningful examples of both. I appreciated the use of diagrams in the article, as it shows what each of them interacts with and how (i.e. A stub doesn’t interact with a database, and is instead a hard-coded value to be grabbed for testing). That wasn’t something that was immediately obvious to me in the assignments, and during our assignment on Stubs specifically it began to make more sense, but I appreciate the way the article laid out the concept in plain text, and made it easier to understand. I also liked that the blog post went over real world applications for each of the fake types, such a using stubs for read/write actions to keep the code and files separate, or using mocks for API testing. Admittedly I am still a little hazy on mocks, but I think by the time we go over it in class, it will all make sense.

 In closing, I really do value stubs as valuable pieces of testing equipment, since they allow me to test code without having to have every intricate detail finished. It makes sense for confirming methods got used, and that a specific path through the program is being followed. Stubs can’t do everything, you can’t really test complex operations on a piece of code that doesn’t work, but for basic probing and testing, I could see myself using stubs a lot more often. It feels like one of those things that I could have used before without thinking about it, which makes sense, as I am the kind of programmer who likes taking things one step at a time, and making sure one piece works before moving on to the next. But now that I have a name connected to the action, I really appreciate it as a tool that will play a big role in my programming career going forward.

 

 Link to the blog post in question: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Testing and Testing (One of them is a Fake).

 Hello!

This week in class we’ve been discussing testing using fakes, more specifically with Stubs. Our first assignment this week told us about the different kinds of fakes used in testing, which I found a little confusing at first, since I would have liked to have seen a more literal example of all the different variants. That is why, for the sake of improving my knowledge on the subject going forward, since this is something we’ll be talking about, I decided to do some reading on stubs and mocks, from a blog post written by Raphael F. on Medium. 

The article spoke at length about the differences between mocks and stubs, and gave some meaningful examples of both. I appreciated the use of diagrams in the article, as it shows what each of them interacts with and how (i.e. A stub doesn’t interact with a database, and is instead a hard-coded value to be grabbed for testing). That wasn’t something that was immediately obvious to me in the assignments, and during our assignment on Stubs specifically it began to make more sense, but I appreciate the way the article laid out the concept in plain text, and made it easier to understand. I also liked that the blog post went over real world applications for each of the fake types, such a using stubs for read/write actions to keep the code and files separate, or using mocks for API testing. Admittedly I am still a little hazy on mocks, but I think by the time we go over it in class, it will all make sense.

 In closing, I really do value stubs as valuable pieces of testing equipment, since they allow me to test code without having to have every intricate detail finished. It makes sense for confirming methods got used, and that a specific path through the program is being followed. Stubs can’t do everything, you can’t really test complex operations on a piece of code that doesn’t work, but for basic probing and testing, I could see myself using stubs a lot more often. It feels like one of those things that I could have used before without thinking about it, which makes sense, as I am the kind of programmer who likes taking things one step at a time, and making sure one piece works before moving on to the next. But now that I have a name connected to the action, I really appreciate it as a tool that will play a big role in my programming career going forward.

 

 Link to the blog post in question: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint 1# Retrospective

 Hello!

 

This week marks the first week of sprint 2 proper, and as such I’ve been tasked with writing about my experiences with sprint 1.

First of all, I implemented RabbitMQ on the inventory backend, which took a while for me to accomplish simply because most of what we are doing in this class is so new to me. I’ll have a link to the merge request at the bottom of the page.

I think our group functioned pretty well during our class meetings, there isn’t that much I would change really. We were productive, everyone was super open to helping each other solve problems, and we laid out the plans for the sprint pretty effectively. 

I think in terms of things that didn’t go very well, I was having a ridiculous amount of problems setting up Visual Studio, and making the backend work. I should be through most of the problems now, (in theory), but during most of the setup process I was unable to build any of the frontends or the backends, which completely halted any progress I could have made early on, though it did give me a chance to read some documentation, and familiarize myself with the backend, so I suppose it wasn’t all bad.

Some things I need to work on going forward is my time management skills, as near the end of the sprint I was rushing to make all of my code work, which was very stressful. Had I managed my time better, this wouldn’t have happened, and going forward I am going to work on improving how I spend my time this sprint. 

Some things that we could work on as a group though, and even now I’m still seeing parts of this problem at the outset of sprint 2, is the fact that not everyone is checking the discord consistently, myself included. Part of the reason why I was so hesitant to join in on discussions in the discord chat was because I was everyone seemed like they already knew what they were doing, and I felt a little silly with some of the problems I was having. I am actively trying to do better, and I am regularly checking the discord and trying to vocalize my questions, but not everyone is online all the time, which makes getting them answered in a timely fashion difficult.

As for which apprenticeship pattern most aligned with this sprint, I would have to say the white belt is pretty spot on. While the context isn’t super relevant (I don’t think anyone called on my expertise), I was pretty consistently facing the problem on educating myself about RabbitMQ and Javascript, both of which I have no prior experience with. Not to mention I was almost in denial about my lack of learning, and for any trouble I was having, the blame was placed on the course load, not me, which isn’t very true. The white belt apprenticeship pattern centers around being willing to unlearn old skills if they are stopping you from effectively learning new ones, which I think was pretty relevant during this sprint. While I don’t think I would have unlearned all of my experience in Java had I read this pattern during the sprint, I think it would have tempered my expectations as to how quickly and easily I would be learning new skills. Learning Java was fairly pain free, but being under a time crunch and being forced to learn a bunch of new skills, it certainly would have been nice to have some idea of how the learning process was going to go.

 

As promised, here is the merge request I generated for this sprint:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/58

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint 1# Retrospective

 Hello!

 

This week marks the first week of sprint 2 proper, and as such I’ve been tasked with writing about my experiences with sprint 1.

First of all, I implemented RabbitMQ on the inventory backend, which took a while for me to accomplish simply because most of what we are doing in this class is so new to me. I’ll have a link to the merge request at the bottom of the page.

I think our group functioned pretty well during our class meetings, there isn’t that much I would change really. We were productive, everyone was super open to helping each other solve problems, and we laid out the plans for the sprint pretty effectively. 

I think in terms of things that didn’t go very well, I was having a ridiculous amount of problems setting up Visual Studio, and making the backend work. I should be through most of the problems now, (in theory), but during most of the setup process I was unable to build any of the frontends or the backends, which completely halted any progress I could have made early on, though it did give me a chance to read some documentation, and familiarize myself with the backend, so I suppose it wasn’t all bad.

Some things I need to work on going forward is my time management skills, as near the end of the sprint I was rushing to make all of my code work, which was very stressful. Had I managed my time better, this wouldn’t have happened, and going forward I am going to work on improving how I spend my time this sprint. 

Some things that we could work on as a group though, and even now I’m still seeing parts of this problem at the outset of sprint 2, is the fact that not everyone is checking the discord consistently, myself included. Part of the reason why I was so hesitant to join in on discussions in the discord chat was because I was everyone seemed like they already knew what they were doing, and I felt a little silly with some of the problems I was having. I am actively trying to do better, and I am regularly checking the discord and trying to vocalize my questions, but not everyone is online all the time, which makes getting them answered in a timely fashion difficult.

As for which apprenticeship pattern most aligned with this sprint, I would have to say the white belt is pretty spot on. While the context isn’t super relevant (I don’t think anyone called on my expertise), I was pretty consistently facing the problem on educating myself about RabbitMQ and Javascript, both of which I have no prior experience with. Not to mention I was almost in denial about my lack of learning, and for any trouble I was having, the blame was placed on the course load, not me, which isn’t very true. The white belt apprenticeship pattern centers around being willing to unlearn old skills if they are stopping you from effectively learning new ones, which I think was pretty relevant during this sprint. While I don’t think I would have unlearned all of my experience in Java had I read this pattern during the sprint, I think it would have tempered my expectations as to how quickly and easily I would be learning new skills. Learning Java was fairly pain free, but being under a time crunch and being forced to learn a bunch of new skills, it certainly would have been nice to have some idea of how the learning process was going to go.

 

As promised, here is the merge request I generated for this sprint:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/58

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.