Dummies, Stubs, Spies, Fakes, and Mocks

Software testing is a crucial component of the software development lifecycle, ensuring that your application functions correctly and meets user expectations. One of the key concepts in unit testing is the use of test doubles, which help isolate the system under test (SUT) by replacing its dependencies. This isolation is essential for creating effective and reliable unit tests. In this blog, we will delve into the different types of test doubles: Dummy, Stub, Spy, Fake, and Mock, and explain their roles and usage with examples.

Dummy Objects

A Dummy object is the simplest form of a test double. Its sole purpose is to fill parameter lists without actually being used in the test itself. Typically, a Dummy can be a null object or an instance with no real logic, used just to satisfy method signature requirements. For instance, when testing a method that requires an interface which the test doesn’t interact with, you could pass a Dummy implementation of this interface. However, a Dummy should never affect the test outcome.

Example:

In this example, dummyBoard is a Dummy since the test does not interact with it beyond instantiation.

Fake Objects

Fakes are more sophisticated than Dummies. They have working implementations, but usually take shortcuts and are simplified versions of production code. Fakes are particularly useful when testing interactions with external resources, like databases. Instead of connecting to a real database, you can use a Fake object that simulates database operations.

Example:

Stubs

Stubs provide canned answers to calls made during the test, usually not responding to anything outside what’s programmed in for the test. They are used to supply the SUT with indirect input to test specific scenarios.

Example:

Mock Objects

Mocks are used to verify interactions between the SUT and its dependencies. They can assert that objects interact with each other in the right way, making them a powerful tool for behavior verification.

Example:

In this case, mock is used to ensure that the Module correctly logs messages when an exception is thrown.

Spy Objects

Spies are similar to Mocks but are used for recording information about how they were called. They can be used for more complex scenarios where you need to assert that certain methods were called a specific number of times or with certain parameters.

Example:

Here, spyLogger acts as a Spy, recording the number of times Log was called.

Understanding the differences between Dummies, Fakes, Stubs, Mocks, and Spies and when to use each can significantly enhance your unit testing strategy, leading to more maintainable and robust code. While these tools offer great flexibility, remember that the ultimate goal is to write clear, concise, and reliable unit tests that effectively cover your code’s functionality.

https://dipakgawade.medium.com/mocking-for-unit-tests-understand-the-concept-221b44f91cd

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

Testing is an important part of coding, and software development. Sometimes though, testing can be tedious work, and creating tests that work properly according to your code can be difficult. This should be the case anyways, as testing is a key aspect to software development, but what if you could do this process a bit more quickly. Creating mocks and stubs can be a good alternative, especially if multiple people are working on different parts of the same project or software. 

In this blog post, June Jung touches upon mock and stub testing. They describe mock testing as “creating a fake version of an external or internal service that can stand in for the real one,” and stub testing as “creating a stand-in, but a stub only mocks the behavior, but not the entire object.” The whole idea of mocks and stubs is to create a fake or a stand-in that does not do anything. This may seem strange, having completely useless methods and functions, but the thing we want to test for is the interactions between the methods and functions. Seeing whether or not they return the correct return values, call the correct methods, etc. This will reduce the amount of time needed to test the functions, compared to testing full, complete functions and methods. Jung says that by using mocks and stubs, you can “reproduce more complex scenarios more easily. For instance, it is much easier to test the many error responses you might get from the filesystem than to actually create the condition.” Jung says this specifically for unit + component testing, but this principle can apply for any kind of testing. In fact, they touch upon multiple cases where mocks and stubs can be used, such as internal functions, integration testing, and contract-based testing. They also provide code examples, and graphs to help you visualize the concept, which can be helpful.

Jung says that as your code grows, your tests should as well, meaning you shouldn’t continue to use the same tests as you continue to write more code, losing the mocks and the stubs. That being said, they’re good to help start, providing a base to continue with. Jung’s blog post is a good resource, as they also have linked another post that goes into the difference between mocks and stubs. It also appears that their blog post is part of multiple posts, which may be worth looking at for more information.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

This week I decided to discuss Unit testing because although we have finished a few activities on the subject, I would like to read up on it to get a better understanding of it. While searching for a blog to discuss, I found this blog called “Unit Testing Best Practices: 9 to Ensure You Do It Right” from Testim. This blog also discusses what a unit test is, why we write them, the benefits of unit testing, how to achieve testable code, who creates them, and the difference between unit testing and integration testing.

The text begins by explaining that unit tests focus on very small parts of the application in complete isolation and compare their actual behavior with the expected behavior. In this section, the idea of complete isolation is thoroughly explained with the idea that “you don’t typically connect your application with external dependencies”. This is what makes unit tests so fast and stable.

The next section explains why they are created in bullet points and have the main ideas bolded. This structuring is helpful to simplify the ideas for the reader and make sure that the main ideas stick out for them. These were the bolded parts of the bullet points in the section: unit tests help you find and fix bugs earlier, your suite of unit tests becomes a safety net for developers, unit tests can contribute to higher code quality, unit tests might contribute to better application architecture, unit tests can act as documentation, and detect code smells in your codebase. I think a lot of the ideas presented were easy to comprehend based on the bolded part but I had to read more about the last bullet point because the term” code smells”(signs that something is wrong with your code ) was not obvious to me. 

The section that explained the difference between integration testing and unit testing was fairly short because they narrowed the main idea down to a few sentences: “It’s all about the level of isolation. While unit tests have to be completely isolated, integration tests don’t shy away from using external dependencies….integration tests offer a more high-level view of the application than unit tests do. Because of that, the feedback they provide is both more realistic and less focused.”

The 9 best practices at the end are titled: Tests Should Be Fast, Tests Should Be Simple, Test Shouldn’t Duplicate Implementation Logic, Tests Should Be Readable, Tests Should Be Deterministic, Make Sure They’re Part of the Build Process, Distinguish Between The Many Types of Test Doubles and Use Them Appropriately, Adopt a Sound Naming Convention for Your Tests, and Don’t Couple Your Tests With Implementation Details. These tips are easy to understand based off of the title alone but throughout each section, the author uses bits of code as examples and bullet points to thoroughly explain each idea. In the future, I will refer to these tips when I need to write tests for a project I will work on.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

In class, we began learning about the use of mocking in software testing. After doing an activity, I realized I only slightly understood the purpose of it. So, I decided to investigate, which is when I found The Art of Mocking by Gil Zilberfeld and Dror Helper.

The article begins by giving an introduction to unit tests for those who might not be familiar. They also give an example in C#, which is the language they use for the rest of the article. However, this does not impact information about mocking besides the syntax of the examples.

Once unit tests are covered, hand-rolled mock tests are introduced: they are classes that the developer(s) code which take the place of the real objects for testing purposes. It might not accurately test the system, but it ensures the business logic of the class works. 

The types of mocking listed are those manually made by the developers and those auto generated by mocking frameworks (Mockito or Moq). The article goes quite in depth into mocking frameworks, in their types, what they do, and what to look for when choosing one. Zilberfeld and Helper also discuss the benefits of mocking, which generally boils down to the fact that mocking cuts loose extra requirements for testing, such as databases and other external/complex resources.

Lastly, the best practices and potential hazards are listed. From what I gathered, the important ones were:

• Only use fake objects when necessary, as too many can create weak/fragile tests
• Understand what you’re testing and the dependency
• At most two assertions/verifications per test

I selected this article because I was struggling a little bit with what mocking was and why it was useful. I had somewhat understood the concept and the idea behind it in class, but needed to go on a deeper dive to get a better grip on it. This resource also seems pretty real, in the sense of it feels homemade and focused; all the important stuff is in the articles themselves, not a subscription or anything. 

This article is superb with its examples and clear, in-depth explanations of unit tests and mocking. The formatting is easy to follow and allows for smooth learning and transitions from concept to concept. I personally believe that mocking is quite useful when applied lightly. I learned that Verify should only be used in fake objects when it’s the only way your program can pass or fail; otherwise, it might not matter whether every method actually calls the expected method. 

This affected me in a positive way as it gave me greater insight to mocking and more confidence in my personal understanding as to why we use it. I expect to apply this in a future job when I might need to test a method that uses database information, but it would take too many resources to use the database for testing purposes.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

In the world of software development, ensuring the quality of a product is paramount. This necessitates comprehensive testing methodologies that cover various aspects of the software development lifecycle. Among these methodologies, Integration Testing and System Testing play crucial roles in ensuring that software meets its requirements and functions as expected. In this blog post, we’ll delve into Integration Testing, System Testing, the role of requirements and test plans, and how JUnit, a widely-used testing framework for Java, assists in detecting defects.

Integration Testing: Integration Testing involves testing the interfaces and interactions between different components or modules of a software application. It verifies that integrated units work together as expected. This testing phase is crucial as it identifies defects that arise from the interaction between integrated components. JUnit provides a framework to write and execute integration tests efficiently, facilitating seamless integration between components.

System Testing: System Testing is a comprehensive testing phase that evaluates the entire system’s behavior against specified requirements. Unlike Integration Testing, which focuses on component interactions, System Testing examines the system’s functionality, performance, security, and other quality attributes. JUnit enables developers to write system tests that validate the system’s behavior as a whole, ensuring that it meets the defined requirements.

Requirements and Test Plans: Requirements serve as the foundation for testing activities. They outline the expected behavior and functionality of the software system. Test Plans are derived from requirements and define the approach, scope, resources, and schedule for testing activities. JUnit allows developers to align test cases with requirements, ensuring comprehensive test coverage. By mapping test cases to specific requirements, teams can verify that each requirement is adequately tested, thereby reducing the risk of undetected defects.

Defects in JUnit: Defects, or bugs, are inevitable in software development. JUnit plays a crucial role in identifying and addressing defects through its testing capabilities. When a test case fails, JUnit provides detailed information about the failure, including the location and nature of the defect. This information helps developers quickly identify and fix the issue, ensuring the software’s reliability and stability.

Conclusion: Integration Testing, System Testing, requirements, test plans, and defect management are essential components of the software testing process. JUnit simplifies and streamlines these activities by providing a robust framework for writing and executing tests. By leveraging JUnit effectively, developers can ensure that their software meets requirements, functions as intended, and delivers a seamless user experience.

Websites:

Link to JUnit Documentation

Get starter with JUnit 5

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Testing code and software can come in many different forms, some may be better than others. In this post, we will look at path testing, or happy path testing. Path testing is representing your code in a linear graph, using nodes and arrows. The nodes represent lines of code, and the arrows dictate the flow of the code or program. It’s a fairly straightforward way of testing, depicting how you want your code to flow, and how the code actually flows. It can help you visualize the execution of your program.

In this blog post, it talks specifically about happy path testing, which is described as “a technique that tests the application through a positive flow to generate a default output,” or “a type of software testing that focuses on the most common and expected scenarios that a user will encounter when using an application.” Essentially, it allows you to see how your code executes in a typical environment. In the blog post, the example of an online shopping site is used, where the typical flow would be a user visiting the website and browsing through the products, adding some products to their cart and going to checkout, entering their shipping address and payment details, and finally finally receiving a confirmation and an email. That’s the happy path the website takes when a normal user goes to shop. This kind of testing ensured that nothing wrong occurred when it came to a normal execution. This is the same thing that happens when applying this testing strategy to your code, going through your code in a normal, typical situation and making sure you will not run into bugs and errors. Some steps to perform happy path testing effectively would be defining the scope and objectives of the testing, designing the test cases and scenarios, executing the test cases and scenarios, analyzing and reporting the results and outcomes, and fixing and retesting the issues and defects. The post also talks about the opposite of happy path testing, and some challenges when it comes to this kind of testing, such as overlooking negative and edge cases and relying on the happy path as a final verdict.

Although happy path testing is an effective testing strategy, it only covers the main part of your code, leaving some areas vulnerable to possible bugs and errors that may not be picked up or detected. But even with that, this is good for an initial testing strategy. It allows you to confirm that your code works as intended and expected when it comes to the most common scenarios of your code. Personally, I’m a fan of this kind of testing, being able to visualize the way my code works is nice. However, I know its limits and when it is effective and when it is not.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.