Changes for page Testing

Summary

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

Details

Page properties

Content

...	...	@@ -3,16 +3,9 @@
3	3	(% style="text-align: justify;" %)
4	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.
5	5
6		-=== ===
	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.
7	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 the functionalities of a system.
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,10 +22,9 @@
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.
	18	+** 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.
	19	+** 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.
26	26
27		-=== ===
28		-
29	29	=== What should be tested? ===
30	30
31	31	(% style="text-align: justify;" %)
...	...	@@ -32,7 +32,7 @@
32	32	Every functionality you expect the software to provide at any moment. You should test:
33	33
34	34	* **Functional Requirements**
35		-** **High-level use cases** that are defined in project requirements. Tests are actually specification translated into code.
	27	+** **High-level use cases** that are defined in project requirements by the customer. Tests are actually requirements translated into code. And customer requirements are usually translated into acceptance tests.
36	36	* **Non-Functional Requirements**
37	37	** **Lower-level use cases** derived from high-level project 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 functions, classes, modules, and components.
38	38	** **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.