Category Archives: Week-14

Learning About Spies in Unit Testing

In my software testing class, we’ve been learning a lot about unit testing and how to make sure our tests are clean and focused. For our group project, I needed to learn more about spies specifically. I came across a blog post on testRigor called “Mocks, Spies, and Stubs” that seemed to offer everything I wanted. I already knew a good bit about mocks and stubs, but spies were still kind of confusing to me, and it doesn’t hurt to review.

Summary of the Blog Post

The post explains how testing tools like mocks, stubs, and spies help isolate the code you’re testing. That just means you’re testing one piece of code without depending on other stuff like a real database or API.

Spies are used when you want to track what happens during a test. For example, you can use a spy to see if a method was called, how many times it was called, and what it was called with. What’s different about spies is they don’t change what the function does unless you want them to. They just track what happens for you.

Why I Picked This

I picked this blog because we’ve been working on our spies POGIL, and we haven’t covered these ourselves in class. I figured now was a good time to figure it out. It also helped me understand how spies are different from mocks and stubs, which I didn’t fully get before.

What I Learned

The main thing I learned is that spies are great when you want to see what a method did without actually changing how it works. That sounds really useful for stuff like tracking clicks or making sure a method only runs once. It also helped me realize that mocks and stubs have different purposes too, as mocks check behavior and stubs give fake data.

How I’ll Use Spies

I think I’ll try using spies when I need to test things that happen in the background or when I just want to see if something got called. They seem useful when you don’t want to mess with the actual code but still want to make sure it’s doing what it’s supposed to, and in a pretty safe manner.

Conclusion

After reading this blog, I understand spies way better. They’re another helpful tool for writing good tests, and now I know when to use them instead of just guessing.

From the blog CS@Worcester – KeepOnComputing by CoffeeLegend and used with permission of the author. All other rights reserved by the author.

JUnit Blues

Hello!

 

With the semester wrapping up pretty quickly, and our last homework assignment being to design an in-class assignment, I’ve been doing some brushing up on JUnit testing. Specifically, assertions, which are the crux of how JUnit tests work, by telling a given test what qualifies as a pass or fail. The assignment me and my groupmates designed revolved around the use of various different kinds of assertions, ones that we didn’t cover heavily in class. 

 As such, this week my blog of choice to read revolves around, what else, JUnit testing. Specifically, the article comes from Medium, who I’ve looked at before, and who seem to be quite the useful resource on covering both broad and specific computer science topics. I wanted to take a look at this specific article, mostly because I wanted to see some of the other topics involved with JUnit that we didn’t cover in class. I intend on running Linux on my main PC once the semester ends, and seeing how to install JUnit on specific hardware instead of importing it as a library is pretty interesting! I am very used to just pulling a library from the top of a piece of code, I am not very well versed in actually installing libraries. Granted, this is the kind of thing that Docker and VS Code are made to circumvent, as you can set it to auto install or include certain dependencies. I also enjoyed reading some of the specific recommendations for writing JUnit specific tests. Some of them we kind of touched on in class already, but it is always nice to keep myself fresh on these kinds of things. Keep tests simple and focused, avoid possible edge cases, the list goes on. Something we didn’t touch on at all in class is the various debugging modes found in JUnit, like JDWP and Standard Streams, which can be useful in troubleshooting a program. Standard Streams for instance places every print that would normally go to the main console, but redirects it to the output strea, which can be useful for seeing exactly what is going on with a program. This kind of angle to me is interesting, as I strongly associate testing with debugging, but we didn’t necessarily cover debugging very thoroughly in class, so perhaps that is something I can look up on my own time. 

 I’ve thoroughly enjoyed my time in this class, some things were a little dry like the Boundary testing near the beginning of the semester, but a lot of the things we learned, like JUnit testing or unit testing in general I can see myself using regularly in industry, and I don’t think I am wrong in thinking that. 

Thank you for reading my blog!

Camille

 

Blog Post: https://medium.com/@abhaykhs/junit-a-complete-guide-83470e717dce

 

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

JUnit Blues

Hello!

 

With the semester wrapping up pretty quickly, and our last homework assignment being to design an in-class assignment, I’ve been doing some brushing up on JUnit testing. Specifically, assertions, which are the crux of how JUnit tests work, by telling a given test what qualifies as a pass or fail. The assignment me and my groupmates designed revolved around the use of various different kinds of assertions, ones that we didn’t cover heavily in class. 

 As such, this week my blog of choice to read revolves around, what else, JUnit testing. Specifically, the article comes from Medium, who I’ve looked at before, and who seem to be quite the useful resource on covering both broad and specific computer science topics. I wanted to take a look at this specific article, mostly because I wanted to see some of the other topics involved with JUnit that we didn’t cover in class. I intend on running Linux on my main PC once the semester ends, and seeing how to install JUnit on specific hardware instead of importing it as a library is pretty interesting! I am very used to just pulling a library from the top of a piece of code, I am not very well versed in actually installing libraries. Granted, this is the kind of thing that Docker and VS Code are made to circumvent, as you can set it to auto install or include certain dependencies. I also enjoyed reading some of the specific recommendations for writing JUnit specific tests. Some of them we kind of touched on in class already, but it is always nice to keep myself fresh on these kinds of things. Keep tests simple and focused, avoid possible edge cases, the list goes on. Something we didn’t touch on at all in class is the various debugging modes found in JUnit, like JDWP and Standard Streams, which can be useful in troubleshooting a program. Standard Streams for instance places every print that would normally go to the main console, but redirects it to the output strea, which can be useful for seeing exactly what is going on with a program. This kind of angle to me is interesting, as I strongly associate testing with debugging, but we didn’t necessarily cover debugging very thoroughly in class, so perhaps that is something I can look up on my own time. 

 I’ve thoroughly enjoyed my time in this class, some things were a little dry like the Boundary testing near the beginning of the semester, but a lot of the things we learned, like JUnit testing or unit testing in general I can see myself using regularly in industry, and I don’t think I am wrong in thinking that. 

Thank you for reading my blog!

Camille

 

Blog Post: https://medium.com/@abhaykhs/junit-a-complete-guide-83470e717dce

 

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

JUnit Blues

Hello!

 

With the semester wrapping up pretty quickly, and our last homework assignment being to design an in-class assignment, I’ve been doing some brushing up on JUnit testing. Specifically, assertions, which are the crux of how JUnit tests work, by telling a given test what qualifies as a pass or fail. The assignment me and my groupmates designed revolved around the use of various different kinds of assertions, ones that we didn’t cover heavily in class. 

 As such, this week my blog of choice to read revolves around, what else, JUnit testing. Specifically, the article comes from Medium, who I’ve looked at before, and who seem to be quite the useful resource on covering both broad and specific computer science topics. I wanted to take a look at this specific article, mostly because I wanted to see some of the other topics involved with JUnit that we didn’t cover in class. I intend on running Linux on my main PC once the semester ends, and seeing how to install JUnit on specific hardware instead of importing it as a library is pretty interesting! I am very used to just pulling a library from the top of a piece of code, I am not very well versed in actually installing libraries. Granted, this is the kind of thing that Docker and VS Code are made to circumvent, as you can set it to auto install or include certain dependencies. I also enjoyed reading some of the specific recommendations for writing JUnit specific tests. Some of them we kind of touched on in class already, but it is always nice to keep myself fresh on these kinds of things. Keep tests simple and focused, avoid possible edge cases, the list goes on. Something we didn’t touch on at all in class is the various debugging modes found in JUnit, like JDWP and Standard Streams, which can be useful in troubleshooting a program. Standard Streams for instance places every print that would normally go to the main console, but redirects it to the output strea, which can be useful for seeing exactly what is going on with a program. This kind of angle to me is interesting, as I strongly associate testing with debugging, but we didn’t necessarily cover debugging very thoroughly in class, so perhaps that is something I can look up on my own time. 

 I’ve thoroughly enjoyed my time in this class, some things were a little dry like the Boundary testing near the beginning of the semester, but a lot of the things we learned, like JUnit testing or unit testing in general I can see myself using regularly in industry, and I don’t think I am wrong in thinking that. 

Thank you for reading my blog!

Camille

 

Blog Post: https://medium.com/@abhaykhs/junit-a-complete-guide-83470e717dce

 

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

JUnit Blues

Hello!

 

With the semester wrapping up pretty quickly, and our last homework assignment being to design an in-class assignment, I’ve been doing some brushing up on JUnit testing. Specifically, assertions, which are the crux of how JUnit tests work, by telling a given test what qualifies as a pass or fail. The assignment me and my groupmates designed revolved around the use of various different kinds of assertions, ones that we didn’t cover heavily in class. 

 As such, this week my blog of choice to read revolves around, what else, JUnit testing. Specifically, the article comes from Medium, who I’ve looked at before, and who seem to be quite the useful resource on covering both broad and specific computer science topics. I wanted to take a look at this specific article, mostly because I wanted to see some of the other topics involved with JUnit that we didn’t cover in class. I intend on running Linux on my main PC once the semester ends, and seeing how to install JUnit on specific hardware instead of importing it as a library is pretty interesting! I am very used to just pulling a library from the top of a piece of code, I am not very well versed in actually installing libraries. Granted, this is the kind of thing that Docker and VS Code are made to circumvent, as you can set it to auto install or include certain dependencies. I also enjoyed reading some of the specific recommendations for writing JUnit specific tests. Some of them we kind of touched on in class already, but it is always nice to keep myself fresh on these kinds of things. Keep tests simple and focused, avoid possible edge cases, the list goes on. Something we didn’t touch on at all in class is the various debugging modes found in JUnit, like JDWP and Standard Streams, which can be useful in troubleshooting a program. Standard Streams for instance places every print that would normally go to the main console, but redirects it to the output strea, which can be useful for seeing exactly what is going on with a program. This kind of angle to me is interesting, as I strongly associate testing with debugging, but we didn’t necessarily cover debugging very thoroughly in class, so perhaps that is something I can look up on my own time. 

 I’ve thoroughly enjoyed my time in this class, some things were a little dry like the Boundary testing near the beginning of the semester, but a lot of the things we learned, like JUnit testing or unit testing in general I can see myself using regularly in industry, and I don’t think I am wrong in thinking that. 

Thank you for reading my blog!

Camille

 

Blog Post: https://medium.com/@abhaykhs/junit-a-complete-guide-83470e717dce

 

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

JUnit Blues

Hello!

 

With the semester wrapping up pretty quickly, and our last homework assignment being to design an in-class assignment, I’ve been doing some brushing up on JUnit testing. Specifically, assertions, which are the crux of how JUnit tests work, by telling a given test what qualifies as a pass or fail. The assignment me and my groupmates designed revolved around the use of various different kinds of assertions, ones that we didn’t cover heavily in class. 

 As such, this week my blog of choice to read revolves around, what else, JUnit testing. Specifically, the article comes from Medium, who I’ve looked at before, and who seem to be quite the useful resource on covering both broad and specific computer science topics. I wanted to take a look at this specific article, mostly because I wanted to see some of the other topics involved with JUnit that we didn’t cover in class. I intend on running Linux on my main PC once the semester ends, and seeing how to install JUnit on specific hardware instead of importing it as a library is pretty interesting! I am very used to just pulling a library from the top of a piece of code, I am not very well versed in actually installing libraries. Granted, this is the kind of thing that Docker and VS Code are made to circumvent, as you can set it to auto install or include certain dependencies. I also enjoyed reading some of the specific recommendations for writing JUnit specific tests. Some of them we kind of touched on in class already, but it is always nice to keep myself fresh on these kinds of things. Keep tests simple and focused, avoid possible edge cases, the list goes on. Something we didn’t touch on at all in class is the various debugging modes found in JUnit, like JDWP and Standard Streams, which can be useful in troubleshooting a program. Standard Streams for instance places every print that would normally go to the main console, but redirects it to the output strea, which can be useful for seeing exactly what is going on with a program. This kind of angle to me is interesting, as I strongly associate testing with debugging, but we didn’t necessarily cover debugging very thoroughly in class, so perhaps that is something I can look up on my own time. 

 I’ve thoroughly enjoyed my time in this class, some things were a little dry like the Boundary testing near the beginning of the semester, but a lot of the things we learned, like JUnit testing or unit testing in general I can see myself using regularly in industry, and I don’t think I am wrong in thinking that. 

Thank you for reading my blog!

Camille

 

Blog Post: https://medium.com/@abhaykhs/junit-a-complete-guide-83470e717dce

 

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

Dice Game Code Review

This week we started to work on our own POGIL activity similar to the Sir Tommy code review. The activity the team has chosen will be a dice game with a specification sheet that expects the people to do the activity based off of the specification sheet. The sheet is going to have specific questions asking what lines contain bugs or have format issues that are not best practice. This will help the students read code more in depth as well as to work together in searching for bugs and format issues. The team is going to meet out of school to determine the questions and how we will go about working on the project. We will also focus on the types of questions we are going to ask in order to make the reader think about what they are reading and to critically think about how they will address the issues presented in the source code as well as test code.
                We are thinking about making a few models explaining and asking questions that send the users to the code to examine it, but also think about much deeper than just the code they are looking at. We will implement Encapsulation, Inheritance and Polymorphism. This means that the users will have to read and understand underlying methods within other methods in order to progress through the models, but it still will be simple enough so that the users do not take up too much time and can focus on the questions rather than the code.

In class yesterday we talked about what other teams were doing, and it was very interesting that everyone took a different approach to the homework. I am still glad my group stuck with sir tommy due to underlying issues with the original that we thought was a good idea to add certain bits and pieces to make the activity more understandable. We did the model questions asking about stubs, mocks, fake and dummies in mind, we dedicated an entire model to these objectives so that the student would understand how each works and how to create and get rid of each for a more optimal solution.

                Overall, this activity showed me how much I learned about different types of testing how to read and understand certain aspects of other people’s codes as well as paying close attention to imports as usually you assume the imports are always correct. I also learned that I have been using dummies, fakes, stubs and mocks without knowing since I did not have prior knowledge to these types of testing. I really enjoyed the class as well as how it was structured and how we had to figure things out on our own as well as a team.

From the blog CS@Worcester – Cinnamon Codes by CinCodes and used with permission of the author. All other rights reserved by the author.

The Best Java Testing Framework: JUnit

Summary of the Source

The blog post introduces JUnit as a unit testing framework designed for the Java programming language, explaining its evolution, core features, and significance. It outlines the primary components of JUnit, such as test cases, test suites, annotations (like @Test, @Before, and @After), and assertions. The guide also discusses test driven development (TDD) and how JUnit supports this methodology by encouraging developers to write tests before writing the actual implementation.

Additional features covered include mocking with Mockito and how to structure test cases for better readability and maintainability. Overall, the article serves as both an introduction and a deeper dive for those wanting to use JUnit effectively in real world software projects.

Reason For Selecting This Blog

I chose this blog post because it well written, and in only a roughly 10 minute read, covers everything there is to know about JUnit, at least as a foundation for starting out with it. It goes over what it is, why its used, and even its history, before diving into how to set the environment up to use it, the shows examples of test cases using JUnit. I think its an overall great resource for any developer who is interested in testing using Java as it covers all the bases.

Personal Reflection

I was introduced to JUnit in university, and learning it there was really helpful towards understanding how testing code works in general. I also liked JUnit especially because it seems very easy to understand and write, where only a couple lines of code could write a test case for your code. Assertions are especially useful as that’s the end result of the test, and with JUnit it’s very simple. One line of AssertEquals tests the expected vs the actual, that’s all it takes to test the correct output. I also see how this framework would be preferred when doing test driven development as each test is separated into different cases denoted by the @Test annotation. This makes it easy to make specific tests for each feature as development continues. I haven’t tried any other testing frameworks but now that I have used JUnit I think it won’t be as confusing to understand a different framework, but since I like how JUnit works I’ll compare the others to it like it’s the gold standard for testing frameworks.

Conclusion

Knowing about JUnit is imperative if you plan on testing code in Java. It has everything that a testing framework could want by making it easy to write, handle multiple test cases, and including assertions. I know that if I ever use Java in the future to test code, I will use JUnit because of how powerful, reliable,  and simple it is.

Citation:
 HeadSpin. (n.d.). JUnit: A Complete Guide. https://www.headspin.io/blog/junit-a-complete-guide

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

Software Technical Review

Week 14 – 5/2/2025

This is my last week of class, and this is kind of bittersweet. The topic for this week was software technical review. While I was working on my last project for the class, I went ahead and read a blog post called “What is Technical Review in Software Testing?” by Ritika Kumari. I did not read this article to find out what a technical review is but to learn more about the process of it.

The article gives a suitable introduction to technical reviews in software testing, stating that technical reviews are formal assessments conducted by technical reviewers to examine software products like documentation, code, and design. Technical reviews are designed to check compliance with standards, enhance the quality of the code, and identify defects at the initial phase of the Software Development Life Cycle (SDLC). The blog discusses how technical reviews reduce the cost of rework, enhance the level of expertise of the team, and get software outcomes in line with business goals.

I picked this article because it is very much in line with the topic we had for this week’s class. The article mixes practical applications, such as Testsigma’s integration for test case management, with abstract concepts, like static testing and peer reviews. Its emphasis on collaborative procedures also aligns with our class’s ideas about agile teamwork.

The blog highlighted the importance of spotting design or code bugs early in development, for if one does so, he or she can save post-release costs up to 70%, as illustrated through the example of re-engineering faulty software. This aligns with the “shift-left” testing philosophy that we examined. Technical reviews are as much about information sharing as they are about error detection. For example, I had not realized how much cross-functional knowledge was built up through walkthroughs and peer reviews. I will look to apply this idea further in automation efforts. Testsigma’s review capabilities, such as automated test case submission and element management, demonstrated how tools could speed up reviews. The blog made me rethink my understanding that reviews are only a “checklist activity.” Rather, they are interactive processes that achieve harmony between teamwork and technical correctness. For instance, the difference between formal defect-oriented inspections and informal knowledge-swap peer reviews led to a better understanding of how to customize reviews according to project requirements. I will promote systematic technical assessments in my next work environment in the future. This class overall was an interesting class and I hope to use the lessons that I have learnt throughout my professional career.

https://testsigma.com/blog/technical-review-in-software-testing/

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Mastering Test-Driven Development

For this blog post, I’d like to discuss an interesting piece by Jeremy D. Miller titled “Effective Test-Driven Development”. It provides some practical tips and advice for developers on how to make the most of Test-Driven Development (TDD). I found it very relatable because it relates to what we’ve been discussing in our software development class, particularly testing and keeping our code in good shape.

Miller’s article delves into TDD, which entails writing tests before coding. While TDD is a common method, he explains how to avoid common issues and adhere to best practices. He discusses how too much setup code, slow feedback, and unnecessary tests can all contribute to slow performance. He contrasts these issues with good habits such as writing quick tests, providing timely feedback, and ensuring tests are clear about what they check in the code.

Miller also discusses how TDD can help with design and quick feedback. He mentions that TDD encourages developers to plan out how their code will look, making it easier to maintain and less buggy. The goal is to make testing an integral part of development rather than a final step, so that problems can be identified early.

I chose this blog because we had only touched on TDD in class and I wanted to see how it applied in real-world software development. I thought it was fascinating that TDD is about more than just writing tests; it’s also about improving code structure. Miller’s suggestions are ones I’d heard of but hadn’t looked into thoroughly. His advice helped me understand how TDD can improve code quality and make life easier for developers, which is extremely useful to me as a student learning to write solid code. Reading this blog made me realize how important it is to write tests that do more than just check if things work; they should also ensure that the code is easy to change later. Miller, for example, discusses “happy paths” in which tests check for expected results and “negative tests” in which errors are handled. This is consistent with what we’ve been learning about testing, but it also gives me a better understanding of how TDD can help clean up and improve code over time.

Miller’s post emphasizes the importance of not rushing through TDD. It’s better to take your time and write clean, manageable code. I found this extremely useful because, as a beginner, I frequently feel the need to complete tests quickly. But Miller reassured me that taking it slowly can save time in the long run by identifying problems early on.

I intend to use TDD more actively in future projects. By writing tests first, I can keep the end goal in mind from the start, reducing the need for major rewrites later. I also feel more confident about refactoring because TDD will help me keep the code solid while I make changes.

In the future, I want to incorporate Miller’s concept of clear intent expression into my code. Writing tests that clearly demonstrate what the code is supposed to do will simplify things for others and help me stay focused when working on larger projects.

Blog: https://jeremydmiller.com/2022/10/03/effective-test-driven-development/

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.