Changes for page Testing

Summary

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

Details

Page properties

Content

...	...	@@ -1,18 +1,7 @@
1		-=== Foreword ===
	1	+* **Ultimate Goal**: Reduce costs and increase productivity.
	2	+* **Definition 'Production Code':** Represents the actual software functionality designed to fulfill project requirements.
	3	+* **Definition 'Test Code':** Often referred to as "tests," is written to verify the functionality of production code.
2	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.
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	16	=== Benefits of Testing ===
17	17
18	18	* **Quality Assurance**
...	...	@@ -22,16 +22,6 @@
22	22	* **Testable Design**
23	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	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.
	14	+** (((
	15	+Tests serve as the most current form of code documentation, capturing the expected behavior of the production code in its present state.
	16	+)))