Before we dive into actual code, let's take a few minutes for an animated overview of what we hope to cover in this series.
Let's dive in and discuss the basics of unit testing. While some tests interact with your entire application - known as end-to-end tests - unit tests are more isolated and targeted. They focus on a single or small collection of classes. In this opening lesson, we'll use TDD to drive out a simple
TagParser class that is responsible for splitting a comma or pipe-separated list of tags into an array.
Before we move on to a new testing term, let's take a bit of time to discuss a few ways to structure and organize your unit tests. First up is the
setUp method, which will run before each test.
Notice how all of our current tests follow the same basic shape: we create a
TagParser instance, we call a
parse() method and pass input to it, and then we assert that the result matches what we expect. In these cases, we can drastically simplify our test class by reaching for PHPUnit data providers. Let's learn how in this lesson.
You would be forgiven for assuming that a unit test may only act upon a single class: one unit test, one class. This is not the case. In plenty of situations, a unit test may touch multiple classes - and even the database if it makes sense.
Now that the full suite for our little Quiz app is passing, we can optionally take a few moments to refactor the code. There's no harm in doing so. If we make a mistake, the tests will immediately return red to notify us. Perhaps this is a good time to extract a
Questions collection class.
In the previous episode, we manually created a test double; however, we can alternatively let our tooling do this work on the fly. In this episode, we'll review PHPUnit's
*Series still in development. Check back often for updates.