BDD: Unit tests vs. Integration tests

[Eyad Salamin]

Warning: A BDD newbie question

Does BDD necessarily involve unit tests or is it ok to have
integration tests as well? I know BDD is not about testing but the
point is that sometimes I have a user story that involves more than a
mere single unit of the software. Am I doing something wrong?

Thanks.

[Derick Bailey]

BDD is a superset of TDD and includes integration testing. In fact,
one of the major advantages of BDD and User Stories is that all of
your tests are driven from the same acceptance criteria: Unit Tests,
Integration Tests, Regression Test Automation, Customer Test
Automation, Exploratory Testing, and any other flavor you can think
of.

BDD stories and acceptance criteria speak to the business process and
value, not to individual functional elements. When a story involves
more than a single unit of the software, you should expect to write
unit/integration tests as part of the development process, and other
forms of test scripts for the real testing process.

[Sean Chambers]

Derick,

On that note, do your BDD tests have assertions on repositories,
services or any other infrastructure concerns. I have found that this
serves very well for end-to-end testing but it adds a lot of noise to
the specific contexts that I am testing.

I am contemplating setting up one set of BDD domain model tests, that
will test domain model logic/flow along with domain services for
acceptance tests, and then have a seperate set of tests that will
perform end-to-end tests.

Should these be seperated like this or is everyone mixing them
together. When we were in the TDD world, there was a clear seperation
between integration/unit tests, but with BDD the line between the two
is blurred somewhat. I have found that people are doing BDD in both
ways.

Any comments or suggestions?

Sean

[Jimmy Bogard]

Maybe I'd like to get clarification on "BDD tests".  This includes a context and a specification/observation.  Sometimes the context is driven from story acceptance criteria.  Sometimes it's "developer" acceptance criteria.  Contexts and observations enforce and strengthen client-driven development.  It shows me the why, where a bunch of assertions lumped at the bottom of a large unit test won't.

I'll still separate my specs between "integration" and "unit" specs.  Integration are used with external dependencies in place, unit they aren't.  Unit-level specs are concerned with directly observable behaviors and interactions.  Integration-level specs include my external dependency tests (like smoke tests for external services, repository/mapper tests, etc), as well as direct verification of acceptance criteria.

But, it's probably just me.

[Sean Chambers]

So therefore, are you using mocks for your integration tests with
assertions? or injecting your services/repositories directly and
testing in the complete context?

Forgive for the remedial questions, I am just getting started with BDD
and trying to establish an idea of how other people are doing their
testing with BDD.

[Derick Bailey]

I'm in the same camp as Jimmy - i still separate my Unit and
Integration tests.


@Sean

> So therefore, are you using mocks for your integration tests with
> assertions? or injecting your services/repositories directly and
> testing in the complete context?

"it depends" :)

if I control all of the external resources - database, file system,
etc. - then I will likely use the real systems for my integration
tests. if you are mocking all of your dependencies, then you may be
doing a 'unit' test... at this point, though, the distinction between
'unit' and 'integration' can get blurry. I honestly would not get hung
up about calling which one what. The most important thing to remember
is that you need to test your application and domain layers
independently of the external services, and you need to test your
actual external services to ensure they are coded and communicating
correctly. Whether or not you inject the real service into your
application for an end-to-end test, or just test the external service
on it's own, or a combination of both, is up to how your team works,
what is important to the test, and whether or not you can trust that
the external service will be available when the test is run.

>
> Forgive for the remedial questions, I am just getting started with BDD
> and trying to establish an idea of how other people are doing their
> testing with BDD.

it's a much more subtle shift than you may be thinking, honestly.
There's no right answer to any of these questions, either. What works
best for you and your team? What experience do you have with standard
TDD styles, and how can you carry that experience into BDD? If you
have a good TDD background, you should really just trust your own
experience and judgment, until you run into something that is painful
- then find a way to alleviate the pain.

[Sean Chambers]

thank you for your comments. i believe I am thinking it is a larger
shift than it truly is.

thanks again!

sean

[Olof Bjarnason]

I'm also a "TDD master" / "BDD novice" and I have gone through the
same "so what am I doing wrong in my BDD-ing?"-phase. Using C#.

I've found it relieving to think "It's not that much a difference".

In practive, I've started to think of my old "tests" more as "checked
examples" -- collected in "stories" or "specs". I've found it slightly
easier to write test code since I started reading about BDD, and I'm
also more forgiving on some "hard TDD principles" I've used before --
specifically I'm not adhering to the DRY-principle at all that much
anymore (Don't Repeat Yourself) when it comes to test-code.

The main idea I'm following instead, is "readability" when it comes to
test code:

// In some Fixture/Story/Spec
[Test]
public void Example1_Assigning_a_variable() {
Given_a_computer();
And_variable_set_to("A", 5);
This_expression_should_compute_to("A*2", 10);
}

My old TDD version this code might have look like:

[Test]
public void AssigningAVariable() {
Computer cpu = new Computer("test computer");
cpu.SetVariable("A", 5);
double result = cpu.Compute("A*2");
Assert.AreEqual(10, result);
}

As you can see, it is mostly cosmetic. But nonetheless, it is somewhat
more readable, don't you think..?

The "literate methods" is just easing the readability of test code. In
my TDD background, I would NOT have written them! Some month into my
BDD experience, I find them the most profound difference from TDD.

cya,

/Olof

2008/7/20 Sean Chambers <dko...@gmail.com>:

[Sean Chambers]

I think this is the mental block I am/was experiencing. I think it
gets some getting used to as it is a re-alignment of where your tdd
thoughts exist. It's difficult to shift your tdd focus from technical
to business specifics.

All the same, this reassures me as well and I feel a lot more
confident about how I am using BDD in the future.

thank you for your comments

Sean

> >> - then find a way to alleviate the pain.- Hide quoted text -
>
> - Show quoted text -