Test driven development for system programmers
Thursday, February 18, 2016
Is it correct that in Behavioral Driven Development, because test scenarios are derived from requirements they are optimized up front and therefore Combinatorial Test Design (CTD) is of no use? I don't think so. In fact, scenarios obtained from requirements may not be optimized or contain holes. Typically, a scenario and/or user story will contain several points of variability. Using CTD the Cartesian product implicitly implied by the user story is modeled and we make sure the number of scenarios to run are optimized and we avoid omissions.
Sunday, January 17, 2016
what is the difference between ATDD and BDD?
There is a lot of confusion around terminology in this context but let me try and answer anyway...:-) ATDD (Acceptance TDD) assumes we iteratively develop the software. At the beginning of an iteration, everyone gets together - development, build, test, and agree on tests that will serve as an acceptance test for the iteration. We then make sure these tests compile, run and fail. Next, developments shot off to develop the iteration. They use TDD to develop the iteration, writing tests, making them fail, writing code, making the tests pass and cleaning up the code, making the tests pass again. Next the acceptance tests are run successfully and we are done. This is ATDD.
When you write tests, and when the tests you are writing are grey/white box. There is always a chance that you'll drive the tests based on the implementation. An extreme case is someone writing unit tests to cover each statement in the code. The best practice is to write the tests based on the black box design of the interfaces you are testing, and then check the code coverage to identify holes in your tests, not vice versa.
BDD emphasis the right approach to writing tests. Move away from the implementation - drive the code based on the external behavior of the interface under test, etc.
Subscribe to:
Posts (Atom)