Join Aaron Dolberg for an in-depth discussion in this video Testing the interaction between objects, part of Programming Foundations: Software Quality Assurance.
- Now that you understand how unit tests look at just a single class or object, you can start thinking about how these objects might interact with one another. So, previously I used the example of a garden and mentioned that when defining it, you would have a class for each individual object and unit tests that are going to look at each of these objects in isolation. Once you've identified each object and validated that these definitions are as intended, you need to start thinking about how these objects work together.
In a garden, you have the vegetables that you grow, but there are other elements that are critical to it functioning properly. You're going to need soil, sunlight, water, and it's common to add fertilizer to get the most out of your plants. However, fertilizer can have different properties. And those properties can produce different results with different plants. Let's say that we're making a game where we didn't want the user to be restricted to the exact kind of fertilizer that they could use in their garden. We wanted them to be able to decide what was best depending on what they were trying to accomplish in our game.
The core properties of our vegetables wouldn't change. And we're going to be allowing some variability in this fertilizer. This is an example of where we would want to test the behavior of two classes interacting with one another. This is a good time for a white-box engineer to start thinking about code-level test cases that we'd want to create in order to validate all possible interactions between each vegetable and the range of variability that we plan to allow in our fertilizer. We're looking to validate the behavior of our objects when we apply one to another.
You may be creating tests that looked at the number of tomatoes that a plant might produce depending on which fertilizer you apply. Here, our tests are going to be executing and ensuring that as we apply different fertilizers to each tomato plant, we get the result that we're expecting. You can see how this is quite different from unit tests, where we just want to make sure that the core definition of an object is unchanged. Here we're looking at interaction and behavior. And these are the kinds of code-level tests that are best created by a white-box engineer.
You're still going to run them in an automated fashion, ideally with every build. And they're going to alert you when something has changed, creating a failure condition. However, we're starting to think more about how the application behaves at a code level. And these kinds of tests can save you a lot of time, because they provide you specific information about where a failure occurs. And when run frequently, you only have to look at changes made since your last successful automated run to debug the source of the issue.
- How to think about quality
- Incorporating black box, white box, and grey box testing into your process
- Understanding your quality goals
- Ranking issues by priority and severity
- Testing core functionality
- Testing the backend
- Using a test case management system
- Interpreting bug models
- Recording defects automatically