Integration tests are a scam?

[federicozuppa]

A week ago I was looking at the presentation Integration Tests are a Scam from Agile 2009 (http://www.infoq.com/presentations/integration-tests-scam)

First thing that came to my mind: Is he cynical with the title? (How can we blame integration tests?) The problem is using integration tests for things that should be tested at the unit level. In other words, the problem is not using integration tests for what they should be used: Just to verify that the integration between the different components is not generating any problem (well.... he is not talking about functional tests, right? Functional tests are integration tests, but everybody recommends having them as way to check that the business features are constructed the way they are supposed to be. )

Second thing: Why is it so hard to define a strategy that makes heavy use of unit tests? (e.g. as suggested by Cohn's pyramid). Is it because TDD is very difficult to learn? Is it because QA departments define the strategy (and they are more into the functional aspects/tests). Is it because of the managers?

Who can we blame for this scam? I think that we all as a community need to take responsibility. We need to understand better the benefits of unit testing, we need to be trained and we need to DO THEM!

Thoughts?

fede
agilebooknote.blogspot.com

[chrs_mcmhn]

--- In agile-testing@..., "federicozuppa" <fzuppa@...> wrote:
>
> A week ago I was looking at the presentation Integration Tests are a Scam from Agile 2009 (http://www.infoq.com/presentations/integration-tests-scam)
>
> First thing that came to my mind: Is he cynical with the title? (How can we blame integration tests?) The problem is using integration tests for things that should be tested at the unit level.

I attended that presentation.  What Rainsberger did was a classic "straw man" tactic.  He described integration tests that no sane programmer would really even attempt, then showed why they were poorly done.  Except that I'll bet that such insane integration tests actually *have* been created, and by more than one team.  

-C

[iceprincess8865]

I attended this presentation too and I think it was my favorite of the conference.  JB makes a compelling argument that relying on integration tests alone for maximum coverage is not a good strategy.  He walked through an example of how to do "isolated object" tests in order to increase coverage.  He wasn't proposing eliminating integration tests, but not relying on them to test all paths.

--- In agile-testing@..., "chrs_mcmhn" <christopher.mcmahon@...> wrote:

>
>
>
> --- In agile-testing@..., "federicozuppa" <fzuppa@> wrote:
> >
> > A week ago I was looking at the presentation Integration Tests are a Scam from Agile 2009 (http://www.infoq.com/presentations/integration-tests-scam)
> >
> > First thing that came to my mind: Is he cynical with the title? (How can we blame integration tests?) The problem is using integration tests for things that should be tested at the unit level.
>
> I attended that presentation.  What Rainsberger did was a classic "straw man" tactic.  He described integration tests that no sane programmer would really even attempt, then showed why they were poorly done.  Except that I'll bet that such insane integration tests actually *have* been created, and by more than one team.  
>
> -C
>

[nails762]

[Sorry for starting a new thread. Long story.]

federicozuppa wrote:
>
> A week ago I was looking at the presentation Integration Tests are a Scam
> from Agile 2009
> (http://www.infoq.com/presentations/integration-tests-scam)
>
> First thing that came to my mind: Is he cynical with the title? (How can
> we blame integration tests?)
>

No, I didn't choose the title cynically. I chose it based on something
humorous my wife frequently says, but that has a kernel of truth in it.

I said it in the opening line: Integration tests are a self-replicating
virus. I see the cycle this way: find integration defects => write
integration tests => plug a few holes => believe integration tests help =>
find more integration defects => write more integration tests => ... try to
act preventatively instead of reactively => start writing integration tests
everywhere => you're dead

I've seen it over and over, as one of the repliers has already written.


federicozuppa wrote:
>
> The problem is using integration tests for things that should be tested at
> the unit level. In other words, the problem is not using integration tests
> for what they should be used: Just to verify that the integration between
> the different components is not generating any problem (well.... he is not
> talking about functional tests, right? Functional tests are integration
> tests, but everybody recommends having them as way to check that the
> business features are constructed the way they are supposed to be. )
>

Correct, I do not mean to include customer tests/business tests/acceptance
tests, whatever you prefer to call them these days. Sadly, teams insist on
writing exhaustive integration tests, and I aim to stop that.


federicozuppa wrote:
>
> Second thing: Why is it so hard to define a strategy that makes heavy use
> of unit tests? (e.g. as suggested by Cohn's pyramid). Is it because TDD is
> very difficult to learn? Is it because QA departments define the strategy
> (and they are more into the functional aspects/tests). Is it because of
> the managers?
>

I don't understand why you think defining such a strategy poses difficulty.
Installing the strategy can pose difficulties when, as you suggest,
programmers and testers do not routinely work together closely and
especially when the organizational chart insists that programmers and
testers have no common managers. That poses similar problems to having
development and maintenance come from separate budget line items.

federicozuppa wrote:
>
> Who can we blame for this scam? I think that we all as a community need to
> take responsibility. We need to understand better the benefits of unit
> testing, we need to be trained and we need to DO THEM!
>

I blame the tests themselves, only because I don't see any value in blaming
any humans for it. If we all learn to hate integration tests, then we'll use
them only grudgingly and when they provide the most value. I think that
would work out for everyone.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://www.thecodewhisperer.com
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

[Carfield Yim-2]

> I said it in the opening line: Integration tests are a self-replicating
> virus. I see the cycle this way: find integration defects => write
> integration tests => plug a few holes => believe integration tests help =>
> find more integration defects => write more integration tests => ... try to
> act preventatively instead of reactively => start writing integration tests
> everywhere => you're dead
>
> I've seen it over and over, as one of the repliers has already written.
>

Excellent! One more attribute that i can sse from integration test is
that is so easy for ppl like to put thing on politic and blame other
team haven't integrated test good enough.

>
> federicozuppa wrote:
>>
>> The problem is using integration tests for things that should be tested at
>> the unit level. In other words, the problem is not using integration tests
>> for what they should be used: Just to verify that the integration between
>> the different components is not generating any problem (well.... he is not
>> talking about functional tests, right? Functional tests are integration
>> tests, but everybody recommends having them as way to check that the
>> business features are constructed the way they are supposed to be. )
>>
>
> Correct, I do not mean to include customer tests/business tests/acceptance
> tests, whatever you prefer to call them these days. Sadly, teams insist on
> writing exhaustive integration tests, and I aim to stop that.
>
>
> federicozuppa wrote:
>>
>> Second thing: Why is it so hard to define a strategy that makes heavy use
>> of unit tests? (e.g. as suggested by Cohn's pyramid). Is it because TDD is
>> very difficult to learn? Is it because QA departments define the strategy
>> (and they are more into the functional aspects/tests). Is it because of
>> the managers?
>>
>
> I don't understand why you think defining such a strategy poses difficulty.
> Installing the strategy can pose difficulties when, as you suggest,
> programmers and testers do not routinely work together closely and
> especially when the organizational chart insists that programmers and
> testers have no common managers. That poses similar problems to having
> development and maintenance come from separate budget line items.
>
> federicozuppa wrote:
>>
>> Who can we blame for this scam? I think that we all as a community need to
>> take responsibility. We need to understand better the benefits of unit
>> testing, we need to be trained and we need to DO THEM!
>>
>
> I blame the tests themselves, only because I don't see any value in blaming
> any humans for it. If we all learn to hate integration tests, then we'll use
> them only grudgingly and when they provide the most value. I think that
> would work out for everyone.
> --
> J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
> http://www.thecodewhisperer.com
> Your guide to software craftsmanship
> JUnit Recipes: Practical Methods for Programmer Testing
> 2005 Gordon Pask Award for contribution Agile Software Practice
>
>
>
> --------------------------------