Drag and Drop Question Drag and drop the steps from the left into the order of the test-driven development cycle. Answer:

Question

Exhibit

Answer Area

Explanation

The question requires ordering the steps of the Test-Driven Development (TDD) cycle, which follows the Red-Green-Refactor sequence: write a failing test, write code to make it pass, then refactor.

Approach. To correctly answer this drag-and-drop question, the test-taker must drag the blue steps from the left column into the yellow target boxes on the right, arranging them in the proper sequence of the Test-Driven Development (TDD) cycle. The correct order, following the 'Red-Green-Refactor' principle, is:

1. Write a test. (Drag 'Write a test.' to 'step 1') - The TDD cycle begins by defining desired behavior with a new automated test.
2. Verify that the new test fails. (Drag 'Verify that the new test fails.' to 'step 2') - This crucial step confirms that the test is correctly written and that the feature it's testing doesn't exist yet (or isn't working as expected), hence the test should fail. This is the 'Red' phase.
3. Write code. (Drag 'Write code.' to 'step 3') - Next, write the minimum amount of production code necessary to make the newly written test pass.
4. Ensure that all tests pass. (Drag 'Ensure that all tests pass.' to 'step 4') - Run all tests (including the new one) to confirm that the new code has fixed the failing test and hasn't introduced any regressions. This is the 'Green' phase.
5. Refactor the code. (Drag 'Refactor the code.' to 'step 5') - With all tests passing, refactor the code to improve its design, readability, and maintainability without changing its external behavior. After refactoring, all tests must still pass. This is the 'Refactor' phase, and the cycle then repeats for the next feature.

Common mistakes.

• common_mistake. A common mistake is to write code before writing a test, or to skip the step of verifying that the new test initially fails.
• Writing code first: If 'Write code.' is placed before 'Write a test.' or 'Verify that the new test fails.', it deviates from TDD's core principle of 'test-first.' This approach often leads to writing untestable code or code that doesn't meet specific requirements.
• Skipping 'Verify that the new test fails.': If this step is missed or placed incorrectly, the developer might write a test that passes even before any code is written. This could mean the test is faulty, doesn't actually test the intended functionality, or is testing something that already works, thus failing to drive development effectively. It's essential for the 'Red' state to be truly red.
• Incorrect ordering of 'Ensure that all tests pass.' and 'Refactor the code.': Placing 'Refactor the code.' before 'Ensure that all tests pass.' after writing code is incorrect because refactoring should only occur when all existing tests are green. Refactoring while tests are failing or not yet verified as passing introduces uncertainty and makes it harder to detect if the refactoring itself breaks functionality.

Concept tested. The core concept being tested is the understanding of the Test-Driven Development (TDD) lifecycle, specifically the 'Red-Green-Refactor' cycle, and the importance of each step in ensuring quality, maintainability, and correct functionality through a test-first approach.

No community discussion yet for this question.