Notes / reminders for myself on BDD / TDD:
- One of the keys to BDD is agreeing on the specs before development with the business owner and the QA engineer.
- Do outside-in TDD. First, write the specs for the functional test level (e.g. Cucumber) and then write the specs at the unit test level.
- If I'm struggling to write the test specs, simply write down in English what you are trying to do.
- Get fast feedback. Only test the small section of tests that are relevant to the code you are changing. You can run the full suite of tests for continuous integration later.
- Whenever you're testing a feature, you should have test cases where it works properly, and test cases where it doesn't work (e.g. throws an error) and you are checking to make sure you have proper error handling.
- Write comments as much as possible while you're developing / writing tests. As you get ready to clean up for a commit / pull request, think about which comments can be turned into actions (e.g. renaming the method so the comment becomes obsolete).
- Focus on testing the most important scenarios. While it's tempting to test every variation and every scenario, the cost is a heavy test suite that takes a long time to run, and therefore discourages people from running it as often as they would otherwise.
- Write your specs so they are detailed. Avoid overly terse specs such as "setupForm():". Add additional context where it makes sense such as "setupForm(): make sure all form fields accept the appropriate types of inputs".
- When testing a class, focus on test coverage for all the major functionality / entry points. Testing every method will result in a tight coupling between the tests and the implementation.