Differences between BDD and TDD?

[Ferdinand Victorinus]

What are the main differences between BDD and TDD? Can both be apllied together?

[Junilu Lacar]

You can get a lot of information about this from Chapter 10, which is available as a sample chapter at Manning

Basically, Tests in BDD have a higher level of abstraction than test in TDD. John recommends that TDD should result in tests that are low-level specifications of the design. For the most part, I agree with this but I think there's room for implementation specific tests coming out of the TDD practice. These kinds of tests are arguably more brittle and volatile but there are many instances where they have helped me work out the details of a specific implementation. Many arguments for BDD and against TDD seem to be based on the assumption that people are doing TDD in a certain way, usually in a way that while common among many developers, is not the ideal way to do it.

In my opinion, BDD and TDD are not mutually exclusive but rather complementing parts of a holistic development approach.

[John Smart]

Junilu sums it up pretty well: BDD and TDD are not mutually exclusive. BDD at a requirements level is about discovering and understanding what features you need to build ("building the right software"). The acceptance criteria that emerge from this process help guide the more detailed coding, where BDD practices can be applied to TDD very naturally (BDD was after all originally a way to teach TDD best practices). You can think of BDD at a unit testing level as "the way many really good TDD practitioners do TDD". If you want to call that "TDD", that's fine. If you want to call it "BDD for APIs", that's fine too. Personally I find the top-down approach that BDD encourages helps focus your TDD efforts. After each test, you ask "what else should this feature do", or, more precisely, "what else should this feature do to satisfy the acceptance criteria"? I also find it useful to think in terms of writing worked examples and specifications for my classes, because that way I understand what I was trying to do when I come back to them later.

BDD also helps you know when you have done enough. Basically, once I have confidence that a class does what it needs to do to help meet an acceptance criteria, I can move on to something else. In practice, this means that I can't think of any other answers to the question "what else should it do?". But if there is significant complexity buried in an implementation, that would probably worry me, so I might pull that out and write low-level specs for that code as well. I think that is what Junilu is referring to.

[Junilu Lacar]

Thanks, John. Yes, we're pretty much on the same page. I got a kick in seeing the kind of JUnit test examples you have in Chapter 10 because most of my unit test look exactly the same.

One thing I moved away from though was using "should" in my test names. When most of my tests started with "should" I just started ignoring the word anyway when I read through the JUnit test report. Besides can_initialize_with_just_name seemed more assertive than should_allow_initialization_with_just_name.

[sagabiz solutions]

Test Driven Development
TDD is the technical team that all cases of unit tests will be written
TDD is installed for testing
TDD encourages technicians to design as little as necessary
TDD help the programmer clearly see what to build and when to stop stop built. TDD focuses aspect of the implementation of the system
TDD methodology is Inside-Out, TDD is more like a development tool for building testable, modular architecture.
Tdd = Refactoring + TFD Behavior Driven Development
then BDD is to take care of the functional aspects thereof. average can be understood by non-developers too
BDD applies the narrative format (Since when, then format)
BDD encourages everyone to build as little as necessary.
The act of writing examples BDD style gives everyone on the project a clear understanding of what it means to a function and when to stop its construction.
BDD focuses on the aspect of system behavior is a BDD methodology outside inward. It starts out by identifying the business results, and drill down into the feature set that will achieve those based outcomes.each is captured as a "story."
BDD = TDD + incremental analysis of needs

Thanks & Regards
Saga Biz Solutions

[Junilu Lacar]

A few ambiguities and inaccuracies in what you wrote:

sagabiz solutions wrote:TDD is the technical team that all cases of unit tests will be written

TDD often involves the users as well since users are often the only ones who can answer questions that can come up during a TDD session.

TDD is installed for testing

Not sure what you mean by "installed" for testing. TDD is practiced, it is not "installed". Also, TDD is focused on design as much as, if not more than, it is on testing. Tests in TDD are used to drive your design thinking but the main activity when you do TDD is usually design.

TDD encourages technicians to design as little as necessary

This statement is ambiguous. TDD encourages simple designs. Constant refactoring and the TDD cycle encourage developers to write small increments in cycles that last maybe 2 minutes. Cycles that last more than 10 minutes are discouraged. TDD is guided by YAGNI and Do the Simplest Thing That Could Possibly Work. You can't do that if you're writing code for hours between running your tests. You are, however, doing a LOT more design and refactoring of the design as you go along.

TDD help the programmer clearly see what to build and when to stop stop built. TDD focuses aspect of the implementation of the system

This could be worded better. TDD helps the developer stay focused on building only the functionality that is currently needed. It still requires a lot of discipline to be able to adhere to YAGNI and DTSTTCPW. I am not clear on what you mean by "focuses aspect of the implementation of the system"

TDD methodology is Inside-Out, TDD is more like a development tool for building testable, modular architecture.

I'm not sure what you mean by "methodology is Inside-Out". TDD is not a methodology. It's just a practice or a technique, if you will. You might say it's a "tool" in the same sense as "knowledge and skills" are tools. You need some knowledge and skills to do TDD effectively. Doing TDD does not guarantee that you'll end up with a testable, modular architecture. Prudent and consistent application of good design choices and practices is what leads to testable, modular architectures. TDD provides the framework for thinking and developing in a way that facilitates and encourages making good design choices but success in doing so still hinges on the developer and his/her skills and discipline. The tools don't make beautiful work products; the skilled artists and craftsmen using the right tools do. A donkey with a Stradivarius cannot play beautiful music in an orchestra.

Tdd = Refactoring + TFD Behavior Driven Development

I really don't know about this one. BDD is often seen as a higher-level form of TDD. Some would argue that BDD is TDD "done right". I would say that BDD can help focus TDD on the more important aspects of the design. Sometimes TDDers can get too caught up in the low-level implementation details and lose sight of the forest for the trees. BDD can help refocus your attention on the big picture. That's not to say that you can't find yourself in a rathole if you do BDD. It all depends on how much discipline and focus the developers have.

then BDD is to take care of the functional aspects thereof. average can be understood by non-developers too

Tools like Cucumber are associated with BDD and help developers produce very human-readable executable tests and documentation. However, good naming and coding conventions can give JUnit tests developed during TDD a very similar level of expressiveness and readability. The key is to choose good names and follow certain coding conventions.

The act of writing examples BDD style gives everyone on the project a clear understanding of what it means to a function and when to stop its construction.

Rather than "function", I would say "feature" - BDD helps you clearly define the different aspects of a feature that you want to develop and test. This is accomplished by having a number of scenarios to illustrate what to expect from a given feature. The scenarios are often a form of "Specification by Example". Edit: I would add that it is not so much the "act of writing examples BDD style" that gives everyone a clear understanding of the feature. Rather, it is the discussions that occur and the collaboration that takes place during the development of the tests that helps the team members involved form a common understanding of what exactly it is they are attempting to build. If one single person does all the writing in BDD style and does not involve other members of the team, that common understanding will likely still not be there.