Skip to Content

Wiki source code of Testing

Version 2.7 by chrisby on 2023/05/29 12:10
Show last authors
1 === Foreword ===
2
3 (% style="text-align: justify;" %)
4 The chapters presented here are a concise summary of more theoretical and high-level knowledge. It is recommended that you are familiar with writing very basic tests and mocks, and understand the concepts of polymorphism and [[dependency injection>>doc:Software Architecture.Dependency Injection.WebHome]] before reading on.
5
6 === ===
7
8 === General ===
9
10 * **Ultimate Goal** of testing: Reduce costs and increase productivity.
11 * **Definition 'Production Code':** Code that provides functionality to meet project requirements.
12 * **Definition 'Test Code':** Often referred to as "tests", it is written to verify the correct functionality of the production code.
13
14 === ===
15
16 === Benefits of Testing ===
17
18 * **Quality Assurance**
19 ** **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.
20 ** **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.
21 ** **Bug Location Detection**: Tests identify bug locations, saving debugging time.
22 * **Testable Design**
23 ** Writing tests automatically enforces design best practices, resulting in a 'testable design' and higher quality code. Good code and architecture are testable, and vice versa.
24 * **Documentation**
25 ** Tests serve as the most current form of code documentation, capturing the expected behavior of the production code in its present state.
26
27 === ===
28
29 === What should be tested? ===
30
31 (% style="text-align: justify;" %)
32 Every functionality you expect the software to provide at any moment. You should test:
33
34 * **Use Cases**
35 ** Use cases defined in project requirements
36 ** Lower-level use cases derived from the high-level project use cases. For example, expected behavior of functions, classes, modules, and components that users of the software do not see.
37 * **Border cases** that could theoretically always occur, such as maximum/minimum values, nulls, invalid input, nulls, negative numbers, empty lists, values with special meaning, exceptions, etc.