Introduction to Types of Testing

Tuning

We established that we want to write a few acceptance tests to prevent breaking something that had previously worked correctly when refactoring code or adding new features.

In the next chapter, we will also drive the development of a new feature by writing the test for it first. This is called “Test-Driven Development,” or “Test-First Development.”

For high-level tests, as opposed to unit tests, the main benefit of writing the test before the implementation is not having to go through the somewhat tedious process of setting up the context in which the new feature runs and can be tested. Instead of logging in, clicking a link, filling out a form, and clicking the “Submit” button, we can have a few lines of code that automate this. This way, we save a lot of time and decrease our level of boredom. If we decide to write the test to protect against regression for this feature anyway, this is clearly a win.

Clarifying the vocabulary

Different people have come up with different names for exactly what each kind of test means. Some call “acceptance tests” what others call “integration tests,” and they disagree on what the differences are. Others use the term “end-to-end tests” to refer to integration tests or acceptance tests. For that reason, I will spell out exactly what I and Ember mean by each kind of test before we actually start writing the tests.

Acceptance tests