Test-driven development Flashcards
TDD
Test-Driven Development (TDD) is a software development methodology where tests are written before the code implementation. It follows the “Red, Green, Refactor” cycle, emphasizing writing failing tests first, writing the minimum code to pass the test, and then refactoring the code.
The three laws of Test-Driven Development (TDD)
- You must write a failing test before you write any production code.
- You must not write more of a test than is sufficient to fail, or fail to compile.
- You must not write more production code than is sufficient to pass the currently failing test.
Referring to the Three Laws according to Uncle Bob, and a unit testing framework you have studied in this course. Describe the workflow of Unit Testing.
Write a Failing Test (First Law),
But don’t write more of the test than is sufficient to fail (Second Law),
Write the Minimum Code to Pass the Test (Third Law),
Execute the unit tests using the testing framework (unittest in this case),
Refactor (Optionally),
Repeat.
Two ways in which unit testing encourages writing modular code.
Unit testing typically follows a modular testing approach, where individual units of code (functions, methods, or classes) are tested in isolation from the rest of the system. This encourages developers to write modular code by breaking down the system into smaller, self-contained units that can be tested independently.
Unit testing encourages the use of dependency injection, a design pattern where dependencies are passed into a module from external sources rather than being hard-coded within the module itself. By injecting dependencies into modules, rather than creating them internally, code becomes more modular and flexible.
Reflect on your experience carrying out test driven development. Describe ONE negative and ONE positive experience.
One positive experience with Test-Driven Development (TDD) could involve the discovery of a critical edge case during the testing phase. For example, while implementing a sorting algorithm, writing tests first may lead to the identification of a scenario where the input list is already sorted in reverse order.
A negative experience with TDD might occur when writing tests for complex or intricate functionalities that are subject to frequent changes. For instance, in a dynamic web application, writing tests for user authentication and authorization features might become challenging as the requirements evolve or security policies change.