Information: http://en.wikipedia.org/wiki/Behavior_Driven_Development
Helps to identify technical requirements for non-technical audience. Leverages the ideas behind literal (narrative) programming (real world language) within the context of outside-in programming (i.e. conversations with users, etc.)
From Wiki: The practices of BDD include:
- Involving stakeholders in the process through outside-in software development
- Using examples to describe the behavior of the application, or of units of code
- Automating those examples to provide quick feedback and regression testing
- In software tests, using 'should' to help clarify responsibility and allow the software's functionality to be questioned
- Test use 'ensure' to differentiate outcomes in the scope of the code in question from side-effects of other elements of code.
- Using mocks to stand-in for modules of code which have not yet been written
Testing portal: http://en.wikipedia.org/wiki/Portal:Software_Testing
STEP: Can be leveraged to introduce group to do TDD. Can be sold as a ‘business’ goal directive. For organizations with medium-to-high resistant cultures, this can go a long way to adopting a solid software development best practices initiative.
BDD is meant to supplement an overall development and implementation methodology.
Context specification style works for non-technical audience. BDD encourages this practice.
Article on CodeMagazine: http://www.code-magazine.com/article.aspx?quickid=0805061
Tools: RSpec (Ruby), MSpec (c#), specUnit
Test classes should reflect story clearly. Look at context inheritance.
Comments (0)
You don't have permission to comment on this page.