There's no two ways about it: terminology in the testing world is incredibly overwhelming. Mocks, stubs, and dummies oh my!
Let's see if we can cut through the noise. Come along as, bit by bit, we break all of these confusing concepts down into something you can easily understand and implement within your own projects.
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.
At the conclusion of the previous episode, I gave you a short bit of homework: two new tests to write and make pass. Let's go over the homework solutions now.
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.
Let's now move on to test doubles. A double is an all-encompassing term to represent some kind of stand-in for your tests. First up is test dummies.
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 createMock() method.
In the previous episode, you got your first taste of mocking. Now, let's take a few moments to discuss a potential downside to this approach. As part of this discussion, we'll review the Classical and Mockist approaches to testing.
Let's move on to a different style of testing that unfortunately might go by many names, dependent upon the development community. Some communities refer to it as feature testing. Others call it end-to-end testing. You might even hear it called acceptance testing or functional testing. While there are often slight differences between these terms, they still generally fall under the same umbrella. Let's have a look in this episode.
There's one obvious issue with the feature tests that we reviewed in the previous episode: they all skip the front-end. While often this is what you want, there will certainly be cases where you need to open a browser, click links, fill out forms, and interact with JavaScript. We refer to this as browser testing. In this episode, I'll use Laravel Dusk to quickly demonstrate the difference between these two approaches to feature testing.
Next up, let’s move on to an approach known as Continuous Integration (CI). This approach was rather confusing to me when I originally learned it, but these days, you’re probably already doing it without realizing it. In this episode, we’ll review a basic workflow for merging content into a central repository that then triggers automated builds and test suites.
این دوره هنوز به پایان نرسیده است و در آینده درس های دیگری به آن افزوده خواهد شد.
