A Brief Introduction to Development Tests and the Test Pyramid
This is a follow-up blog post I wrote called “Test-Driven Development (TDD): why every programmer should learn it.” Read it on Level Up Coding here. Full disclosure, the concepts laid out in this blog post are derived from a Udemy course by Boris Paskhaver. Check it out here.
There are different types of tests a programmer can use when it comes to creating a test suite. This blog post aims to define those tests. We will also look at the ‘Test Pyramid,’ to get a better understanding of which tests to implement more in your test suite.
Unit Tests
This type of test is a way of testing a unit. The focus of a unit test is an individual unit of code in the program. Elements are tested in isolation, these are the smallest piece of code that make up a larger codebase. A unit can refer to a single class, module, object, or method. A huge advantage to unit test is it can reduce bugs in newly developed features or when changing existing functionality. One downside is that it can get tedious having to write many tests when there are many elements, or units.
End-to-end Tests (E2E)
This type of test focuses on a feature and its interaction with the entire system. The elements that were tested in the unit tests are tested together. An advantage of this type of test is that the completed program is tested as a whole and with a good deal of confidence. However, the downside could be that the specs are hard to write which can make them more likely to break and run slow.
Integration Tests
Integration tests fall somewhere in the middle between Unit and E2E tests. It doesn’t test one single unit or the program in its entirety. The focus may be a small feature and/or how two classes may work together.
Manual Tests
These are the tests that the programmer will manually test on their own. They will come up with different test cases to see what outputs arise from them. This should be avoided since we like having the computer runs tests for us, mostly to cut down significant time. However, manual tests are still great to have since the computer may not have caught a specific use case or the test code hasn’t been created.
The Test Pyramid
When it comes to writing a test suite, it’s a good idea to have all four tests together. These tests were designed to be used with each other. Unit tests should take the bulk of the test suite followed by integration tests, E2E tests, and then manual tests.
Which test is best?
The concept of this test pyramid has been around for a while, but teams still struggle to put it into practice properly. Why is that? The test suite is designed to test the program you are creating. The programmer tailors the test code that works best for the program. This is why teams struggle to implement the test pyramid because the best test suite really depends on the type of program you are building.
Thanks for reading and hope this helps clarify the different types of tests you can use when creating a test suite.
Happy coding 😄
