Skip to Content

Changes for page Testing

Last modified by chrisby on 2024/06/20 14:42
From version 4.17
edited by chrisby
on 2024/04/01 12:41
Change comment: There is no comment for this version
To version 4.20
edited by chrisby
on 2024/04/01 12:43
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,11 +1,8 @@
1 1  === Foreword ===
2 2  
3 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 Engineering.Architecture.Dependency Injection.WebHome]] before reading on.
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 before reading on.
5 5  
6 -(% style="text-align: justify;" %)
7 -The **ultimate goal of testing** is to reduce costs and increase productivity. Development with testing is faster and safer than without.
8 -
9 9  === Benefits of Testing ===
10 10  
11 11  * **Quality Assurance**
... ... @@ -12,6 +12,7 @@
12 12  ** **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.
13 13  ** **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.
14 14  ** **Bug Location Detection**: Tests identify bug locations, saving debugging time.
12 +** For these reasons, **development with testing is faster and safer than without**.
15 15  * **Testable Design**
16 16  ** Writing tests automatically forces developers to apply specific design best practices, resulting in a [[testable design>>doc:.Testable Design.WebHome]] that improves code and architecture testability, an important quality criterion.
17 17  * **Documentation**
... ... @@ -31,7 +31,7 @@
31 31  ** **Performance requirements**
32 32  ** **Security requirements**
33 33  ** **Load requirements**, when software is expected to handle a certain number of requests per second.
34 -* At any level of abstraction, you should always test **happy path** requirements, where everything works as expected, and **unhappy path** requirements, where something goes wrong or an unusual input is provided. Writing tests for the latter makes the software robust against misuse.
32 +* At any level of abstraction, you should always test **happy path** requirements, where everything works as expected, and **unhappy path** requirements, where something goes wrong or an unusual input is provided. Writing tests for the latter makes the software robust against failures and misuse.
35 35  
36 36  === Related Topics ===
37 37