I have a question related to Acceptance Test Driven Development (ATDD). According to the process, I start every feature with an acceptance test (end-to-end test). I commit these tests and they are failing as expected. The problem is that I should somehow distinguish between the acceptance tests that are failing because the feature is not complete and those that are failing because of some regression. What is the best practice for organizing CI process with ATDD?
4
votes
You can tag gherkin fixtures with attributes - you could have an attribute for incomplete tests (if you're using a gherkin-based ATDD framework like SpecFlow or Cucumber)
- levelnis
Don't have personal experience with it, but I was at a softrware company who showed me how they developed software. They wrote the acceptance tests in Selenium, and they used sprint IDs in their names as a convention. That way they could easily see if the failed tests were new or old. Is that what you mean? (ps: good question, surprised that there is so little response)
- bas
1 Answers
3
votes
The tests that are not implemented yet should not be running in CI. The point of CI tests is to catch regressions. Catching "not done yet" problems creates a situation where red builds are "normal" and ignored. This is the worst outcome possible.
There are a lot of ways to do this, and the best will depend on your context. The simplest is to write the acceptance test first, but don't check it in until it passes (ie, you implemented the feature).
