Foreword
The chapters presented here are a concise summary of more high-level knowledge about testing. It is recommended that you are familiar with writing very basic tests and mocks before reading on.
Benefits of Testing
- Quality Assurance
- Automated Testing: Minimizes the need for human source code checking or manual testing, providing a cost-effective way to ensure continuous quality assurance and the correct functioning of software at all times.
- Early Feedback: Tests provide immediate bug feedback. This is especially true for detecting accidentally introduced bugs caused by code changes. The earlier bugs are detected, the cheaper they are to fix. This also eliminates the fear of introducing bugs when writing or modifying code.
- Bug Location Detection: Tests identify bug locations, saving debugging time.
- For these reasons, development with testing is faster and safer than without, also see Test-Driven Development.
- Testable Design
- Writing tests automatically forces developers to apply specific design best practices, resulting in a testable design that improves code and architecture testability, an important quality criterion.
- Documentation
- Always Up To Date: Tests serve as the most up-to-date form of code documentation, capturing the expected behavior of the production code in its current state or of a third-party library.
- Code Is Best Documentation: Good tests are quick and easy to understand because they are written in an expressive language that developers speak fluently. In addition, the actual documentation with its long texts is often skipped anyway.
- Behavior Is Easier To Understand Than Implementation: Tests are a clearer representation of behavior than the implementation itself. Tests specify the input for a given code and assert the expected output, providing an intuitive understanding that's easier to grasp than the intricacies of production code. Simply put, what code does is easier to understand than how it does it.
What should be tested?
Every functionality you expect the software to provide at any moment. You should test:
- High-level business use cases defined by the customer in project requirements. Tests are essentially requirements translated into code. And customer requirements are typically translated into Acceptance Tests.
- Lower-level technical use cases derived from high-level business use cases that are not directly visible to end users, but form the backbone of software functionality. This includes the expected behavior of the underlying components, modules and units.
- You should always test happy path requirements, where a user story works as expected, and unhappy path requirements. For the latter, we need chaos engineering, i.e., verifying that a system can withstand unusual conditions makes it robust against failure and misuse.
- Border cases that could theoretically occur, such as maximum/minimum values, nulls, invalid input outside the permissible value range, zeroes, negative numbers, empty lists and values with special meaning.
- Error cases: Exceptions, dependencies returning errors, a file access or existence problem, network problems etc. Anything that could potentially go wrong.
- Failure Injection: For example, at the operational level, this could include actions such as killing processes, shutting down servers, disconnecting networks, insufficient hardware resources (CPU, memory, disk space), even simulating entire data centers failing due to disasters, etc., while verifying that the system is still fully functional, available, and able to automatically recover.
- Security requirements: For example, simulate all potential attack scenarios and verify that the software can withstand them.
- Performance requirements: Interactions with software often need to be completed in a certain amount of time.
- Load requirements, when software is expected to handle a certain number of requests per second.
Table of Contents