Ultimately, your practice of TDD should reflect your needs and those of your development team and application. There is a lot of room to customize your team's approach and methodology when practicing TDD. Most successful development teams follow similar strategies. In your continued practice of TDD, you should remember these guidelines.
Names are important. Good names make it easy to identify the purpose and function of a class, method, or variable. Conversely, bad names make it almost impossible to identify the intent of these objects. When naming your tests, be sure to be specific about what you are naming your classes and test methods. Class and method names should clearly spell out the preconditions or assumptions for your tests, the action or functionality you are testing, and what result you are looking for to constitute a successful test. Keeping names descriptive is a key component of keeping your code readable and maintainable.
The first D in TDD stands for driven. This means that before writing code to add functionality to an application, you should write a test. By necessity this means that each unit of functionality has at least one test. For many types of functionality, one test is not enough. Tests that test only the “happy path” of your code are easy to write. Unfortunately, these tests often do not tell the whole story.
It's important to test your code not only for the ...