BDD x ATDD - what is the difference?

[Marcelo Zeferino]

Friends,

In concept and in practice, what is the difference between BDD and
ATDD? In my point of view both are very similar but BDD is more code
related than ATDD. In other hand, ATDD is more related to feature than
BDD.

What is the point?

Thanks a lot!

Cheers,
Marcelo Zeferino

--
Enviado do meu celular

[Wes Williams]

There is another thread happening on this discussion in the group already.  Read the thread titled 'Defining BDD'.  There are some great link in that thread.

wes

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To post to this group, send email to behaviordriv...@googlegroups.com.
To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/behaviordrivendevelopment?hl=en.

[Marcus Hammarberg]

Hmm interesting for me it's the other way around (if I get you
right).

I think of ATDD as an extension of TDD that gives you an acceptance
criteria to start from, that tells you when you have tested enough. I
first ran into this term in the excellent book (Growing Object-
Oriented Software Guided by Tests, http://www.growing-object-oriented-software.com/).

BDD I have always seen as something more business facing. The
scenarios are written in natural language collaborative with the
stakeholders and describes the desired behavior of the system.

From the BDD scenarios you can start coding outside in, in the same
manner as the ATDD-tests so they are similar but I think that ATDD is
more developer facing and BDD faces other stakeholders (as well).

That my two cents.

And (as Wes Williams said below) there are some great stuff being said
on this matter in another thread.

/Marcus Hammarberg
www.marcusoft.net
Avega Group

[Franz Allan Valencia See]

Good day,

Thanks Neel for that write-up. I see your point. TDD is now being used to describe the art of using Automated Testing (particularly Unit Testing) as a design practice (yes, other nice stuff comes with it like executable documentation, regression testing, etc ...but these are nowadays considered more of a positive side-effect than the end goal).

And although I agree with most of the first half of your write-up, it seems though that the 2nd part (the benefit part) is more of the benefits of ATDD than BDD.

Personally first, these are the main differences between ATDD & BDD:
In BDD, you start of by defining the functional specification, then working downwards by creating domain unit behaviour specifications to every domain unit collaborator that you discover. These domain unit behaviour specifications may be unit or integration tests, but the functional specification must be an end-to-end integration test (or something really close to those ends). Throughout this process, just like in TDD, the top-most test (the functional specification) will fail over and over again, while the domain unit behaviour specifications will fail-then-pass for each domain collaborator & for each behaviour. And after the domain collaborators have all passed, and when there's no more domain collaborators discovered (and assuming the design is correct), then the functional specification will pass (note: refactoring can be done after every 'pass' state).

And as for ATDD, the main focus is mainly on that functional specification. You first capture the requirements/use case/user story/etc as an executable functional specification (normally starting out with empty implementations to be filled up later). Afterwards, you can now work on the functional specification's implementation or the functionality itself (ideally, the functional specification's implementation first, but IMHO, it's acceptable to do both in parallel (i.e. if you have a dedicated QA resource)). As to how these functionalities are implemented, this are no longer specified by ATDD (of course, due to its roots, the suggested/implied way is TDD/BDD/<? extends T>DD). The main concern for ATDD is more on the capturing of these high level functionalities and implementing these functional specifications in a maintainable way. Is ATDD a subset of BDD? - no, in the way that BDD is not a subset of TDD. Automated functional testing is so much of a pain that I believe it merits its own sets of disciplines & principles.

Given those, I now have the following definitions:
* TDD is when you use Automated Testing (usually Unit Testing) as a design practice.
* BDD is when you use Automated Testing to flesh out & capture domain logic starting from the (high-enough) functional testing down to the domain unit logic,
* ATDD is when you use Automated Testing to flesh out & capture the high level requirements (end-to-end or near-end-to-end), and use those to drive the development.

..and the following benefits:
* TDD ensures high quality code.
* BDD ensures high cohesion between technical implementation and the domain (i.e. the functionality is implemented internally in a manner that makes sense to business - via the domain units & behaviour that domain experts understand),
* ATDD ensures system functionalities are implemented properly.

Needless to say, all three complements each other.

Thoughts?

Thanks,
--
Franz Allan Valencia See | Java Software Engineer
fran...@gmail.com
LinkedIn: http://www.linkedin.com/in/franzsee
Twitter: http://www.twitter.com/franz_see

[1] http://neelnarayan.blogspot.com/2010/07/bdd-is-more-than-tdd-done-right.html

On Mon, Jan 31, 2011 at 7:30 PM, Neel Lakshminarayan <neel.n...@gmail.com> wrote:

I felt that BDD is more than TDD. I tried to capture that in this write-up.

http://neelnarayan.blogspot.com/2010/07/bdd-is-more-than-tdd-done-right.html

Neel

On Mon, Jan 31, 2011 at 1:44 AM, Franz Allan Valencia See <fran...@gmail.com> wrote:

I am no BDD authority but I've always regarded (and describe to others that) BDD (and ATDD as well) is what TDD was supposed to be.

BDD for me is basically TDD with a reemphasis on the following - you verify behavior and not methods, and you write a "specification" instead of a test script (note: the specs may be implemented as test scripts underneath).

(OT: while ATDD for me is TDD with a reemphasis on writing your automated functional tests as specifications which is written from the start to define what the whole system is supposed to do (ie. Feature, use case, etc) and executed repeatedly until said behavior is implemented (and the bonus as always is that from then on,it acts documentation and regression testing)).

Cheers,
Franz

On 29 Jan 2011 06:23, "Johnno Nolan" <johnn...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To post to this group, send email to behaviordriv...@googlegroups.com.
To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/behaviordrivendevelopment?hl=en.

--
Twitter:neelnarayan

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To post to this group, send email to behaviordriv...@googlegroups.com.
To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/behaviordrivendevelopment?hl=en.

--
Franz Allan Valencia See | Java Software Engineer
fran...@gmail.com
LinkedIn: http://www.linkedin.com/in/franzsee
Twitter: http://www.twitter.com/franz_see

[Neel Lakshminarayan]

I think BDD leverages important aspects of ATDD, TDD and other agile practices. So, yes, some of the benefits in BDD do accrue from ATDD and TDD.

 

But,  BDD is also a lot about using the “right words” - an important differentiator. That’s very subtle, but very powerful. If all you did was TDD but substituted the word “behavior” for “test”, you should already begin experiencing a paradigm shift (towards BDD). Very different questions start popping into your head. Instead of “What should I test?” , you might hear “What’s the intended behavior?”.  This will cause you to think differently and therefore, you will write very different code.

 

I have found words to be very powerful. Using the right words, causes the right thoughts. The right thoughts, lead to correct actions. Correct actions, lead to desired outcomes. As much as this sounds like philosophy, following this approach will lead to writing “Software that matters and works correctly”.  I think BDD facilitates this wonderfully, tying ATDD, TDD and other agile practices such as collaboration and communication together to deliver more than what each of them could have delivered individually.

 

It makes the whole greater than the sum of its parts.

Neel

[Elizabeth Keogh]

On Mon, Jan 31, 2011 at 10:26 PM, Neel Lakshminarayan
<neel.n...@gmail.com> wrote:

> But,  BDD is also a lot about using the “right words” - an important
> differentiator. That’s very subtle, but very powerful. If all you did was
> TDD but substituted the word “behavior” for “test”, you should already begin
> experiencing a paradigm shift (towards BDD). Very different questions start
> popping into your head. Instead of “What should I test?” , you might hear
> “What’s the intended behavior?”.  This will cause you to think differently
> and therefore, you will write very different code.

This.

Neel, have you blogged this anywhere? If not, would you please
consider writing up your experiences with BDD? The language you're
using here expresses exactly the kind of thing that I've experienced,
too.

Cheers,
Liz.

--
Elizabeth Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

[Neel Lakshminarayan]

I haven't blogged this particular piece. I can certainly do that in the near future. I will let this group know when I've done it. I guess it can be a follow up to the piece below that I posted earlier.

http://neelnarayan.blogspot.com/2010/07/bdd-is-more-than-tdd-done-right.html

Neel

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To post to this group, send email to behaviordriv...@googlegroups.com.
To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/behaviordrivendevelopment?hl=en.

--
Twitter:neelnarayan

[Franz Allan Valencia See]

Although I do agree with you that the change in language is very very important, I think "tying ATDD, TDD" seems a bit too much for me :-)

I agree that BDD advocates using the "right words", and I agree that it has a profound change. Because by doing so allows for ubiqutuous language which means you're going to be implementing the features in the same language as that of the domain experts (sounds like DDD? because I really do think there's a really strong correlation between the two. Of course, DDD then goes off with Entities vs Values, Anti-Corruption Layer, etc, while BDD approaches it in a testing, err... behaviour-manner). And I think that is the main strong point of BDD. Just like TDD's main strong point is to improve design, and ATDD's main point is to focus work on "software that really matters" as you have put it :-)

Of course, we could say that BDD does what TDD & ATDD does but more, but the same can be said for TDD with BDD & ATDD, or ATDD with BDD & TDD - each of these xDDs tackle what the other 2 xDDs does, but the focus is different :-)

Cheers,

--
Franz Allan Valencia See | Java Software Engineer
fran...@gmail.com
LinkedIn: http://www.linkedin.com/in/franzsee
Twitter: http://www.twitter.com/franz_see

[Elizabeth Keogh]

Yes, Ubiquitous Language is shamelessly stolen from DDD. In addition
to using a ubiquitous language for the *business* domain, though, BDD
also provides a ubiquitous language for the *software* domain.

That's the real difference, for me, between a scenario and an
acceptance test. Business stakeholders can give you a scenario in
which XYZ happens. They don't often recognise that that's all an
acceptance test is, really.

Similarly, TDDers don't always recognise that they're providing some
examples that show how the code behaves and how you can use it.

On Tue, Feb 1, 2011 at 5:40 PM, Franz Allan Valencia See

--

[Greg Young]

UL != BDD

Its a difference between user view and domain expert view. Often the
domain expert view has more things inside of it. I find BDD focuses
more on a shared language than an ubiquitous.

Greg

--
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
de votre attention

[Greg Young]

Although in honesty from a vocabulary perspective BDD focuses more on
the ubiquitous language (globally shared language) and DDD focuses on
a language between domain expert and the team (which is more like
language in a context)