9

I am coming from a TDD mindset into BDD. I understand that using BDD is to focus on ensuring the behaviours and business goals of software are being met.

What confuses me is that if I start using BDD in place of TDD, it seems I'm not able to test at such a low-level. For example, when writing a test with a TDD mindset, I might test that properties have been attached to the scope:

it('should attach properties to scope', function () {

  expect(MainCtrl.items.length).toEqual(1);
});

In doing this, another developer knows the assignment to scope was expected and required for future use, saving them some debugging should they have removed the assignments or changed defaults etc.

This example doesn't define a behavior so can't be considered BDD. Of course, I could rewrite the test description to make it more behavior orientated, such as, "when the page loads, setup properties for later use so the user can do so and so..." but this seems too abstract.

Is it a done-thing to use both TDD and BDD at the same time? Have BDD available to define the behaviors for all parties involved in the project (including non-technical) and TDD specifically for developers?

Ian Lunn
  • 1,354
  • 14
  • 20

1 Answers1

9

Short answer, yes.

However, the distinction between BDD and TDD is not as you've mentioned and I'd like to clear up what "ensuring the behaviours and business goals of software are being met" really means :)

BDD precedes, envelopes and goes beyond the development stage. BDD is far more than a syntax and not just a change from the word "test" to the word "should". BDD is actually a paradigm to writing software that involves the end-to-end business. This page explains that:

BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

BDD starts with deliberate discovery, where a group of people get together and flesh out the details of a story using scenarios. The group of people is typically made up of 1+ of each of the following disciplines: product, development and QA - also referred to as the three amigos. This exercise precedes development and is very good at identifying defects before you even start development and it creates better specifications through a shared understanding.

Once you have a good story with good scenarios, you can drive development using an outside-in testing approach:

Outside-in testing

This means you start with the acceptance test (avoid the UI if you can), and as you drive development into the system, you employ TDD at the integration and unit levels for things like your services and domain objects. Here you can choose any syntax you like, and what you have used above with "should" is fine.

If you're using Javascript, we created an open source tool called Chimp to make the process of outside-in testing easy.

Finally, I recommend you look at the following links:

Xolv.io
  • 2,483
  • 1
  • 15
  • 17
  • One of the best responses I've seen in this topic. Question, why would you say to "avoid the UI if you can" in the outside-in context though? – Luis Vasconcellos Jun 01 '19 at 23:19
  • 2
    Thanks @LuisVasconcellos. Outside in (in my experience) is best done at the domain levels. You want to make sure the domain works. Look at hexagonal architecture or the clean architecture approaches. Here's a link that will explain what I mean: https://khalilstemmler.com/articles/domain-driven-design-intro/ When you test using the UI you're drawing the boundary of the test to be too large and as a result you get domain leakage. There is a difference between the core biz domain and the UI domain. Here's another link about that :) https://dannorth.net/2011/01/31/whose-domain-is-it-anyway/ – Xolv.io Jun 03 '19 at 00:06