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