BDD vs TDD.
BDD vs TDD.
Seems like an innocent question: which is better behaviour-driven development or test-driven development.
It’s a trick question. I don’t think either is better, they’re related but orthogonal.
Object-oriented programming at the design level deals with the abstraction and encapsulation of behaviours and attributes. At the lowest level that’s creating classes to model “real-world” object. That’s a pretty shallow or one-dimensional view of OO. Methodologies like Agile attempt to keep the stakeholders involved throughout the development process. The difficulty with that has been the tendancy of software developers to completely abstract themselves at the macro level from the stakeholders: “You tell me what you want, and I’ll go away for a while and do it”. At the application-level this has proven to have issues. Depending on the complexity of what the developers are working on, by the time they deliver it may be irrelavent. Agile attempts to compress that tendancy into iterations–where an application will contain several iterations, allowing the developers to involve the stakeholders through the lifecycle gaining valuable feedback and becoming responsive to change. The issue now is how to manage what each iteration involves and how to sucessfully deliver those iterations.
Concepts like Domain-Driven Design (DDD) attempt to make better use of object-orientation by bringing encapsulation and abstraction into the design process by better abstracting the implementation details from the stakeholders. Abstraction is done by continually evolving a domain model.
Test-driven development at the very simplest means writing test before writing code and was incubated by Agile methodologies.
Behaviour-driven development is an adjunct to TDD in that it adds a level of testing between “unit” and “integration” to test the behaviour of objects. Unit testing should continue to be done: testing the specifications of methods and classes.
with : Uncategorized