Join Aaron Dolberg for an in-depth discussion in this video Putting unit tests in context, part of Programming Foundations: Software Quality Assurance.
- In our last section we talked about UI automation, but there are a lot of different kinds of automated tests that a quality engineer might employ. We've already discussed some, like performance testing. However, when a lot of people think about automated testing, they envision a white-box tester creating suites of code-oriented tests that can run when a build is kicked off to alert the team of newly injected bugs early on. It's true that this is absolutely the kind of task fit for a white-box tester.
However, it's important to spend a little time on what some of these tests really are. You see, not all automated tests should be written by a quality engineer. What I'm talking about here is unit tests. Now, you shouldn't assume that it's impossible for a white-box tester to create unit tests, and there are some situations where it might make sense. However, most of the time a unit test should be written by a developer. To understand what a unit test is, you need to understand one simple concept in object-oriented programming, and that's the concept of a class.
You can think of a class as the definition of an object that you intend to create instances of in your application. You will specify all available states and behaviors for this object such that each instance created from this class is identical with the same properties as all the other copies. Now, unit testing is when you create tests for a class in complete isolation of the larger system. You're interested in validating the definition of an object and you want to be alerted if this definition changes from your expectations.
For example, say we were creating a garden. You'd have a class for each component of your garden, so you would likely have a unique class for each vegetable that you planted to have in your garden. Now, if we intended to grow tomatoes, we'd have a class that defined all of the exact properties of our tomatoes for this particular garden. If our intention was to grow red tomatoes, it would be specified in the class. If we wanted a unit test for this, we would have a test that checked to make sure that our tomatoes were red and only red, such that if somewhere along the way our definition of a tomato changed, our unit test would fail.
This kind of testing is helpful because the unit test is being run against the application code, such that if it changes and produces unexpected results, we're notified. It's a way for a developer to create a definition and ensure that the object still meets that definition as designed. Yes, it's true, if a white-box engineer fully understands these definitions they can absolutely assist with writing unit tests, but it's not best practice, and there are more common white-box activities that take place a level above unit tests, and we're going to talk about those in our next movie.
- 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