Automate Your Tests: Sleep Better at Night
Ah, the eternal question: to write automated tests or not to write automated tests? This is the question that has been deliberated by software developers since the dawn of time (or at least since the dawn of software development practices). But fear not, dear reader, for I am here to shed some light on the matter. In today’s world of rapid software development and the ever increasing list of requirements and their associated complexities, testing your code with a suite of automated tests has become a must-have rather than a nice-to-have addition to any software project. So sit back, relax, and let me convince you why automated testing is the secret ingredient to a successful project.
Why Write Tests?
Before we answer that question let’s first look at what a test is, what do we mean by a ‘test’? A test, depending on the type, is code that is written to test a specific function or feature of your codebase in different scenarios to ensure it behaves as expected in both a positive and negative context if applicable.
We’ll cover the different types of test later on, but first let’s identify why we should write tests at all. In my humble opinion the biggest and immediate benefit you get with a suite of crafted automated tests is (drumroll please)..
Confidence.
Writing automated tests provides you, your team and other stakeholders with confidence that the code you have written works and behaves exactly as intended. Having automated tests within your software project also supports continuous integration pipelines by automatically testing new code changes and verifying that they integrate correctly with the existing codebase. This automation enables the deployment process to proceed quickly and reliably based on the outcome of the test suite passing or failing. Furthermore, automated testing provides new developers with another means (other than just reading the codebase) to obtain a clear understanding of the project and it’s state, allowing them to confidently make changes without introducing unintended defects or breaking existing functionality.
In summary, automated tests Are Your Code’s BFF, always there to save the day and ensure everything runs smoothly. And let’s be real, any future developers who inherit your project will be throwing you virtual bouquets for the gift of a well-tested codebase.
Types Of Test
There are many different types of testing that can be classed as automated tests including but not limited to:
- Unit tests
- Integration tests
- End to End tests
- Functional tests
- User Interface (UI) tests
- Contract tests
- Performance Tests
Each type of test comes with it’s own array of benefits and responsibilities. Let’s take a look at unit tests as an example. A unit test is responsible for independently testing the smallest testable parts of an application, usually at method or class level to ensure each unit of code performs as intended. Unit tests are often prevalent in test suites due to their ease of writing, granularity, and quick execution time and is not uncommon for a majority of the tests in a suite to be unit tests. In contrast, end-to-end tests are usually more intricate set up, develop, maintain, and execute compared to other types of tests because they verify the entire system from start to finish, including all internal components and external system interactions.
As you can see, there’s a few different types of test you could use. You may not need half of these types of tests depending on your project and you could need all of them and more, ultimately it’s all about what suits your project best.
Test Concepts
The previous testing approach mentioned above that consists of many unit tests and fewer end to end test is a common testing approach with software projects and is often referred to as the Test Pyramid.
The Test Pyramid is a conceptual model for software testing that provides a visual representation of the overall testing strategy of a project, showing the different layers of testing and the types of test each layer comprises of. At the base of the pyramid you typically have the unit tests then followed by integration tests at the next layer and ending with end to end tests at the top of the pyramid. See the following image as an example:
Now I hear what you’re saying, are there other testing models that are used? Yes! Another testing model is the Testing Trophy (Oooh!) which is similar to the Test Pyramid in terms of test composition but the ordering of which is slightly different.
In the Testing Trophy Model, the majority of the test suite comprises of integration tests, with a new section at the bottom called static. The static section isn’t another type of test that you need to write, its a section to represent any linters/static code analysis tools you may be using to catch typos, null references and the like early on. This model focuses on integration tests to provide the bulk of the test coverage of an application as opposed to the test pyramid which uses unit tests to do so. See the following image as an example:
There is no right or wrong test concept to use, it all depends on your project and what approach suits it better.
Conclusion
In conclusion, writing automated tests for your project is essential for ensuring the quality, readability and maintainability of your code. Automated tests can catch bugs quicker in the early stages of development which saves time, money and resource in the long run. Automated tests also provide a safety net for future code changes either made by you or future developers, making it easier to make modifications without introducing new unexpected issues. With a suite of automated tests in place you can rest easy knowing your code works as intended and shouldn’t (fingers crossed) display any unexpected behaviours. So pick a suitable testing approach, write some automated tests and sleep better at night. Sweet Dreams!
