Test Driven Development (TDD) advocates the practice of programming by writing tests first, writing the code to make the tests pass, then refactoring to optimize the code and the overall design of the application without breaking the tests. Obviously this leads to a comprehensive test suite that covers what your code does, because it was the contract of what was to be built.
1. Write tests first: Write tests that show the common usage of a given class first (plus some
boundary or edge cases).
2. Write code with clear intentions: write focused classes with narrow/targeted responsibilities and use good naming conventions. It is easier to write a test for a component for which the intent is known, especially important for future the re-testing or enhancing.
3. Test everything: If it can break, test it. If code has in-determinant effects or output that’s not clear from its interface, test it. Unless there is a comprehensive set of tests, any assurance of a component quality is just an illusion.
4. Build a test harness early in the development: Set up testing as part of the build
and if possible and use a test framework that integrates with your IDE.
5. Code enough to pass the unit tests: The task is complete when the unit test is complete.
Code shouldn’t be checked in unless it has a comprehensive set of unit tests and those tests pass.
6. Tests use cases and requirements: Regardless of what requirement gathering techniques you use, map those requirements to a clearly defined set of tests.
7. Enable continuous integration: continuous integration supports running unit tests before code is checked in and after any code has been checked in to prove the build quality.
8. Don’t over-test: Test enough to cover functionality. Add new tests as defects appear. t.
No comments:
Post a Comment