A brief introduction to TDD
Often, as developers, we prefer to run our applications locally as we develop them. This is a huge time saver in many cases as we rinse and repeat making updates or debugging while running our code through the well-worn TDD cycle of red, green, iterate. This means that, we start by creating a new test that proves some aspect of a feature that we want our code to have before the feature code is created—such that the test, when run, will fail (go red). We then create the actual feature code to satisfy the previously written test that enables the test to pass successfully (go green), followed by repeat iterations of debugging the feature code or creating more tests using the same workflow. The good side effect of TDD is that, not only do we end with code that works as intended—delivering on the promise of value the feature embodies; but, we also have clearly written tests that can serve as documentation for each feature.
With TDD, we get provable code that has many...
