| ... |
... |
@@ -1,11 +1,8 @@ |
| 1 |
1 |
=== Foreword === |
| 2 |
2 |
|
| 3 |
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 Engineering.Architecture.Dependency Injection.WebHome]] before reading on. |
|
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. |
| 5 |
5 |
|
| 6 |
|
-(% style="text-align: justify;" %) |
| 7 |
|
-The **ultimate goal of testing** is to reduce costs and increase productivity. |
| 8 |
|
- |
| 9 |
9 |
=== Benefits of Testing === |
| 10 |
10 |
|
| 11 |
11 |
* **Quality Assurance** |
| ... |
... |
@@ -12,7 +12,7 @@ |
| 12 |
12 |
** **Automated Testing**: Minimizes the need for human source code checking or manual testing, providing a cost-effective way to ensure continuous quality assurance and the correct functioning of software at all times. |
| 13 |
13 |
** **Early Feedback**: Tests provide immediate bug feedback. This is especially true for detecting accidentally introduced bugs caused by code changes. The earlier bugs are detected, the cheaper they are to fix. This also eliminates the fear of introducing bugs when writing or modifying code. |
| 14 |
14 |
** **Bug Location Detection**: Tests identify bug locations, saving debugging time. |
| 15 |
|
-** For those reasons. Development with testing is faster and safer than without. |
|
12 |
+** For these reasons, **development with testing is faster and safer than without**, also see [[Test-Driven Development>>doc:Software Engineering.Agile.Extreme Programming.Test-Driven Development.WebHome]]. |
| 16 |
16 |
* **Testable Design** |
| 17 |
17 |
** 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. |
| 18 |
18 |
* **Documentation** |
| ... |
... |
@@ -25,7 +25,7 @@ |
| 25 |
25 |
(% style="text-align: justify;" %) |
| 26 |
26 |
Every functionality you expect the software to provide at any moment. You should test: |
| 27 |
27 |
|
| 28 |
|
-* **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. |
|
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 Test>>doc:Software Engineering.Agile.Extreme Programming.Acceptance Tests.WebHome]]. |
| 29 |
29 |
* **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. |
| 30 |
30 |
* **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. |
| 31 |
31 |
* If needed: |
| ... |
... |
@@ -36,4 +36,4 @@ |
| 36 |
36 |
|
| 37 |
37 |
=== Related Topics === |
| 38 |
38 |
|
| 39 |
|
-See also the articles on [[Test-Driven Development>>doc:Software Engineering.Agile.Extreme Programming.Test-Driven Development.WebHome]] and [[Acceptance Testing>>doc:Software Engineering.Agile.Extreme Programming.Acceptance Tests.WebHome]]. |
|
36 |
+See also the articles on and . |
