Changes for page TDD Workflow Example

Summary

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

Details

Page properties

Content

...	...	@@ -4,7 +4,7 @@
4	4
5	5	### The Role of Git
6	6
7		-The goal of TDD is to take many small, simple, and safe steps iteratively. A save step, meaning all tests pass, should be physically saved to provide the ability to roll back. Whenever something goes wrong, the last save step is not far away, and rolling back is cheap because only an insignificant amount of code and effort is thrown away.
	7	+The goal of TDD is to take many small, simple, and safe steps iteratively. A save step, meaning all tests pass, should be physically saved to provide the ability to compare current changes to the last safe step, or to roll back. If something goes wrong, the last safe step is not far away, and finding the problem in a small snippet of changed code makes debugging much easier.
8	8
9	9	* When a test passes, **stage the changes** via `git add .`
10	10	* When a test passes and is complete, **commit the staged changes** via `git commit -am "..."`
...	...	@@ -29,6 +29,6 @@
29	29
30	30	***Always-Passing Test**
31	31
32		-An always-passing test is a test that passes independently of the production code it tests. They are problematic because they indicate working functionality while verifying nothing, and they are hard to detect. Avoiding them should be a major concern. A common cause of always passing tests is the absence of an assertion in the test, so in the workflow above, the assertion is added to the test first.
	32	+An always-passing test is a test that passes independently of the production code it tests. They are problematic because they indicate working functionality while verifying nothing, and they are hard to detect. Avoiding them should be a major concern. A common cause of always passing tests is the absence of an assertion in the test, so in the workflow above, the assertion is added to the test first to prevent such cases.
33	33
34	34	If a test is suspected of always passing, mutate the production code to try to trigger a failure of that test. One approach is to simply change the return value of the function being tested to a definitely wrong return value, often null, empty collection, bad data, etc. If the test fails, all is well, we can undo the production code mutation and move on. Otherwise, the test is proven to always pass, so it must be debugged until the cause is found and fixed, which is achieved when the test can finally fail.