In an enterprise setting, does one apply BDD principles alongside of, or instead of, "traditional" unit testing?

Question

I have a problem visualising how the gap is closed between coarse-grained, n-tier boundary, high level, automated acceptance testing and lower level, task/sub-task scope Unit Testing.

My motivation is to be able to take any unit test in my system and be able to follow backwards, through coverage, which scenario(s) make use of that unit test.

I am familiar with the ideas of BDD: An extension of TDD and writing scenarios at the high level solution design level in the Gerkin format, and driving these scenarios using tools such as JBehave and Cucumber.

Equally, I am familiar with the humble unit test at the utility or task level, and using xUnit to test through the various paths of the function.

Where I begin to come unstuck, then, is when I try to imagine these two disciplines applied together in an enterprise setting.

Perhaps I am going wrong because you tend to use one approach or the other?

In an attempt to articulate my thoughts so far, let's assert that I am right to believe that both are used.

In an agile world, user stories are broken down into tasks and sub-tasks, and in an enterprise setting, where the problems are large and the number of developers per story are many, those tasks and sub-tasks are distributed amongst a team of people with specialist problem solving skills.

Some developers, for example, may specialise in mid-tier Development, develop a controller layer and continue to work downwards. Others may specialise in UI development and work from a controller layer upwards.

Developers may therefore share implementation of a single string of tasks which, when glued back together again, will implement the story.

In this case, it seems to me that cycles of TDD at the task and sub-task level is still necessary, to ensure that the efforts of these developers collaborate correctly within one layer and from one layer to the next (mocking collaborators).

Working in this way implies a certain amount of high level solution design up-front, so contracts between layers are agreed and respected. Perhaps this is articulated as a sequence diagram and perhaps this emerges during the task breakdown session for the story.

Yet, on the other hand, we have the value of defining the BDD acceptance tests at a higher level to configure that all of the blocks work together as expected - a form of super Integration Test, I suppose.

I suppose the answer I am looking for here, aside of the simpler yes/no to the question of "both", is an explanation/worked example of how I and a team of developers start out with a single n-tier scenario and end up with an implementation in an enterprise setting, where we've been able to break the tasks up into layers and share them amongst ourselves and work in parallel to turn the BDD scenario test from red to green, all the while ensuring that the the code we write is only written because the scenario calls for it, and at a fine grained level the code we have written is appropriately unit tested following cycles of TDD at the task and sub-task level as we go.

If, of course that is correct?

Answer 1

I think that there is a common misconception as to what BDD means, that BDD means that we are now writing our tests using tools like Cucumber, SpecFlow, etc instead of traditional unit tests.

That is not the case. BDD is more a way of thinking that moves our focus in the tests from the technical aspects to the more business oriented aspects. Also see this P.SE answer: https://softwareengineering.stackexchange.com/a/135246

A few tools were born out of the BDD world, e.g. Cucumber and RSpec.

Cucumber is not intended as a testing tool - it is intended as a collaboration tool. It allows programmers to collaborate with the business in order to write business specifications.

But you shouldn't use Cucumber because you are in an enterprise setting. You should use Cucumber because you can get customer involved in the software development process. If you do not have the customer strongly involved, you should think twice before using a tool like Cucumber.

Also read this blog post from Aslak Hellesøy (creator of Cucumber): https://cucumber.pro/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool.html

RSpec on the other hand is a unit test tool. But with a strong focus on describing the requirements for your code, e.g. by using strings as your test case names, instead of function names. For example

describe "Login application service" do
  context "user has given 3 incorrect passwords already" do
    it "rejects the user when a correct password attempt is made" do
            ...
    end
  end
end

This is a test for a specific component in the system, but the focus of the tests are the business requirements that that particular component helps fulfill.

If you use these two types of tool together, you get a process like this:

Just picked from a random image search for "BDD Cycle". You can exchange SpecFlow with Cucumber, JBehave, TickSpec, or whatever. And you can replace MSpec with RSpec, or even traditional xUnit type frameworks.

If you are under operating in a regulated industry, e.g. medical, or finance, you get the benefit that your software is both validated and verified if you use both.

Collaboration tools helps to make sure that your software fulfill business requirements, because the business collaborated in writing them*. Therefore your software has been validated.

Unit test make sure that each component works correctly, Therefore your software has been verified.

So in your case I would suggest: Continue to write unit tests. Strive to focus on business requirements rather that implementation details. If, and only if, you can get the customer involved, write acceptance tests in a cucumber style.

* This requires that the specification actually describes business process, and not user interfaces, a mistake that many people new to cucumber makes. Also see this site for more: http://www.elabs.se/blog/15-you-re-cuking-it-wrong