Skip to Content

Changes for page Testing

Last modified by chrisby on 2024/06/20 14:42
From version 4.25
edited by chrisby
on 2024/04/01 13:18
Change comment: There is no comment for this version
To version 4.27
edited by chrisby
on 2024/05/18 09:52
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -15,7 +15,7 @@
15 15  * **Documentation**
16 16  ** **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.
17 17  ** **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.
18 -** **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 concrete, low-level implementations. Simply put, what code does is easier to understand than how it does it.
18 +** **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.
19 19  
20 20  === What should be tested? ===
21 21  
... ... @@ -29,7 +29,7 @@
29 29  ** **Performance requirements**
30 30  ** **Security requirements**
31 31  ** **Load requirements**, when software is expected to handle a certain number of requests per second.
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.
32 +* 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.
33 33  
34 34  === Table of Contents ===
35 35