Changes for page Testing

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,7 +1,7 @@
1	1	=== Foreword ===
2	2
3	3	(% style="text-align: justify;" %)
4		-The chapters presented here are a concise summary of more high-level knowledge. It is recommended that you are familiar with writing very basic tests and mocks before reading on.
	4	+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.
5	5
6	6	=== Benefits of Testing ===
7	7
...	...	@@ -14,22 +14,25 @@
14	14	** 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.
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		-** **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 is often simply skipped over.
18		-** **Behavior Is Easier 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.
	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 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
22	22	(% style="text-align: justify;" %)
23		-Every functionality you expect the software to provide at any moment. You should test:
	23	+Every functionality you expect the software to provide at any moment. Depending on the overall requirements, you should test:
24	24
25		-* **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>>doc:Software Engineering.Agile.Extreme Programming.Acceptance Tests.WebHome]].
26		-* **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.
27		-* **Border cases** that could theoretically occur, such as maximum/minimum values, nulls, invalid input outside the permissible value range, zeroes, negative numbers, empty lists, values with special meaning, exceptions, etc.
28		-* If needed:
29		-** **Performance requirements**
30		-** **Security requirements**
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.
	25	+* **High-level business requirements** defined by the customer in project requirements. Tests are essentially requirements translated into code. And customer requirements are typically translated into [[Acceptance Tests>>doc:Software Engineering.Agile.Extreme Programming.Acceptance Tests.WebHome]].
	26	+* **Lower-level technical requirements** 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.
	27	+* **Happy Path Requirements**: Always test scenarios where a user story works as expected.
	28	+* **Unhappy Path Requirements**: Test scenarios where things do not go as planned. This includes
	29	+** **Edge cases**: Test for maximum/minimum values, nulls, invalid input outside the allowed range, zeros, negative numbers, empty lists, and values with special meaning.
	30	+** **Error cases**: Handle exceptions, dependencies that return errors, file access or existence problems, network problems, and other potential failures.
	31	+** **Failure injection (chaos engineering)**: Perform chaos engineering to test the robustness of the system against unusual conditions. This includes actions such as killing processes, shutting down servers, disconnecting networks, simulating insufficient hardware resources (CPU, memory, disk space), and even simulating entire data center failures due to disasters. Ensure that the system remains functional, available, and able to recover automatically.
	32	+** **Security requirements**: Simulate potential attack scenarios and verify that the software can withstand them, ensuring robust security measures.
	33	+* **Performance requirements**: Interactions with software often need to be completed in a certain amount of time.
	34	+* **Load requirements**: Verify that the software can handle the expected number of requests per second under normal operating conditions.
	35	+* **Stress requirements**: Run tests with an unusually high number of requests to ensure that the system can handle extreme load conditions without catastrophic failure and to determine its breaking point.
33	33
34	34	=== Table of Contents ===
35	35