Changes for page Testing

Summary

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

Details

Page properties

Content

...	...	@@ -1,4 +1,13 @@
1		-* **Ultimate Goal**: Reduce costs and increase productivity.
	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. Development with testing is faster and safer than without.
2	2	* **Definition 'Production Code':** Code that provides functionality to meet project requirements.
3	3	* **Definition 'Test Code':** Often referred to as "tests", it is written to verify the correct functionality of the production code.
4	4
...	...	@@ -19,9 +19,13 @@
19	19
20	20	=== What should be tested? ===
21	21
	31	+(% style="text-align: justify;" %)
22	22	Every functionality you expect the software to provide at any moment. You should test:
23	23
24		-* **Use Cases**
25		-** Use cases defined in project requirements
26		-** 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.
27		-* **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.
	34	+* **Functional Requirements**
	35	+** Use cases that are defined in project requirements. Tests are actually specification translated into code.
	36	+** Lower-level use cases derived from high-level project use cases are not directly visible to end users, but form the backbone of software functionality. This includes the expected behavior of the underlying functions, classes, modules, and components.
	37	+* **Non-Functional Requirements**
	38	+** **Border cases** that could theoretically occur, such as maximum/minimum values, nulls, invalid input, zeroes, negative numbers, empty lists, values with special meaning, exceptions, etc.
	39	+** **Performance requirements**
	40	+** **Security requirements**