Third Law of TDD

Correct Answer: Beth should remove or comment on the untested production code, create a failing test, then re-include or uncomment the code.

In the spirit of Test Driven Development (TDD), Beth should stick to the Third Law which insists that one should not write any production code unless it is to make a failing unit test pass. Thus, the appropriate action would be to remove or comment on the untested production code, create a failing test, and then re-include or uncomment the code, as this course of action follows the diligence required by the TDD regulations. The answer suggesting she reviews TDD documentation and leaves the code is incorrect as it ignores the violation of the Third Law. Similarly, the suggestion to carry on with the next phase of coding is misguided as it ignores the issue at hand. Ignoring the Third Law, as advocated in the fourth answer, is also not considering the TDD rules, which stresses continuous testing before and along the development.

Correct Answer: Over time, the codebase may become prone to bugs as modifications without failing tests can lead to untested or poorly tested code.

The Third Law of Test-Driven Development (TDD) states that you should not write more of a unit of code than is sufficient to fail a not-yet-written unit test. The potential implications of violating this law, as Martin did, is what the correct answer delves into. Over time, the codebase may indeed become prone to bugs as modifications without failing tests can lead to untested or poorly tested code. This increases the likelihood of creating or perpetuating software defects. The second answer contradicts the basis for Test-Driven Development's sequential process, which is meant to prevent exactly what Martin did. Thus, the statement that the order of testing and coding is subjective is incorrect, as it neglects the purpose of TDD The third answer, that the code will run faster as tests slow down execution time, is misleading because TDD does not primarily prioritize code execution speed. Its main focus is reducing the possibilities of bugs through rigorous testing, and any effect on execution time is secondary Finally, the last answer, stating that fewer tests mean less code complexity, is incorrect. In TDD philosophy, tests are an essential part of managing complexity, as they help the developer understand the code and ensure it behaves as expected. Removing or reducing tests can lead to greater, not lesser, code complexity.

Correct Answer: He should delete the written code, write a failing test first, and then re-write the code.

According to the third law of Test-Driven Development (TDD), Michael should first delete the code he wrote, then create a failing test, and only after that, re-write the code. This is important because it helps ensure that the new feature has complete test coverage and verification of its functionality right from the start. The purpose of TDD is to think of the tests first, which can lead to a cleaner design and less chance of errors. In contrast, the options suggesting to continue coding without a failing test, to write a failing test but let the existing code stay, or wait for peer review do not align with this TDD principle and could lead to incomplete test coverage, bugs, or a delay in identifying problems.