| ... |
... |
@@ -2,8 +2,6 @@ |
| 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 |
|
| 5 |
|
-=== === |
| 6 |
|
- |
| 7 |
7 |
=== Benefits of Testing === |
| 8 |
8 |
|
| 9 |
9 |
* **Quality Assurance** |
| ... |
... |
@@ -13,15 +13,6 @@ |
| 13 |
13 |
* **Testable Design** |
| 14 |
14 |
** 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. |
| 15 |
15 |
* **Documentation** |
| 16 |
|
-** Tests serve as the most current form of code documentation, capturing the expected behavior of the production code in its present state. |
| 17 |
|
- |
| 18 |
|
-=== === |
| 19 |
|
- |
| 20 |
|
-=== What should be tested? === |
| 21 |
|
- |
| 22 |
|
-Every functionality you expect the software to provide at any moment. You should test: |
| 23 |
|
- |
| 24 |
|
-* **User Cases** |
| 25 |
|
-** Defined in project requirements |
| 26 |
|
-** Use cases derived from the high-level project use cases. For example, expected behavior of functions, classes, modules and components that the user does 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. |
|
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 |
+))) |
