Changes for page Test-Driven Development

Summary

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

Details

Page properties

Content

...	...	@@ -6,7 +6,7 @@
6	6	* **High Quality**: Writing testable code forces the developer to apply design best practices on the fly, resulting in a [[testable design|doc:Software Engineering.Testing.Testable Design.WebHome]].
7	7	* **Speed and Safety**: Code changes that inadvertently introduce new bugs are caught immediately, ensuring correct code behavior at all times, enabling faster overall development.
8	8	* **Courage**: There should be no fear of making changes to the code, such as refactorings. Testing ensures behavioral stability while leaving the implementation open to change.
9		-* **Fun**: Writing tests before writing production code is more fun because writing production code becomes a challenge to be solved by trying to pass the test. On the other hand, writing production code first makes writing test code boring and feels like an unnecessary burden because we already know how the code works.
	9	+* **Fun**: Writing tests first is more fun because writing production code afterwards becomes a challenge to be solved by trying to pass the test. On the other hand, writing production code first makes writing test code boring and feels like an unnecessary burden because we already know how the code works.
10	10
11	11	### Three Laws of TDD
12	12
...	...	@@ -17,8 +17,9 @@
17	17	**Remarks**
18	18
19	19	* **Not compiling is a failure**: For example, if the test code requires a function from the production code that has not yet been defined, compilation will fail.
20		-* **Workflow**: In practice, you start writing a test until it fails, then switch to production until it passes, switch back to test code until it fails, and so on until the feature is complete. This leads to a very fast oscillation of switching between test code and production code. Ideally, the last test passed within the last few minutes. The less the better.
	20	+* **Workflow**: In practice, you start writing a test until it fails, then switch to production until it passes, switch back to test code until it fails, and so on until the feature is complete. This leads to a very fast oscillation of switching between test code and production code. The last test should have passed within the last few minutes.
21	21	* **Debugging**: The very short TDD cycles result in far fewer bugs. Bugs may still occur, but they are often trivial and don't require debugging. Experienced developers are capable of debugging, but they do not spend much time on it because of the consistent use of TDD.
	22	+* **The tests need to run fast** so as not to block the developer from doing his task. See this [[test execution speed enhancing article|doc:Software Engineering.Testing.Enhance Test Execution Speed.WebHome]].
22	22
23	23	### Code Coverage
24	24