ISerializable - Roy Osherove's Blog

Pingback from  Arjan`s World    » LINKBLOG for May 31, 2008

This is a great analogy.  Hope u do not mind if I steal that from you when I talk about the differences between the 2?

I'm sorry, but that's one of the worst possible analogies I've read about the subject so far.

It's not great, because integration testing is about testing, not about getting things done. Your analogy describes the process of getting the money from everyone so the single bill can get payed properly. But integration testing is to assure things work correctly across units. So a better analogy would have been that you use a single unittest which checks the single bill in integration testing and you use 1 test per couple/single in the case of unit testing to see if the bill is payed properly (it's testing after all!).

If you wanted to illustrate the point of TDD being used as a design principle, which gives you unittests as a bonus, vs. writing code which requires you to write integration tests afterwards, (which is what I read in your analogy), the analogy is impossible, as the two  _testing_ areas aren't comparable.

@Frans,

See I totally disagree with your asserting about integration testing.  With Roy's example about integration testing other people (couples) are required to know about out dependencies such as who bought what, and how much it cost.

Nowhere does it speak to anything about 'getting things done'.

"See I totally disagree with your asserting about integration testing.  With Roy's example about integration testing other people (couples) are required to know about out dependencies such as who bought what, and how much it cost."

Nowhere does it speak to anything about 'getting things done'."

I quote: "There is a lot of interaction going on to decide who pays for what and who has already paid."

Since when is that about testing? Testing is solely about: does code piece X do what it should do with input I? If not -> fault, if it does -> move on.

The analogy tries to describe a wrong picture where unit-tests apparently lead to a properly payed bill and integration testing leads to a lot of hassle. So i.o.w.: the analogy tries to sell you the idea that unittests: good, integration tests: bad. However they're not about the same thing, so they can't even appear to be compared in the same analogy

It would have been way better if Roy would have described integration testing as a way to test the independently tested units together:

1) use unittests to ... test units individually, independently of other units

2) use integration testing to test a group of units together, you know... integrated.

Of course, some people will now point out that the group of point 2 is also a unit, but that's not true: integration tests focus on testing how pieces of code which independently seem to work properly also work together properly. I.e.: if I call the save method on an o/r mapper's context, the units: entity graph analyzer, entity graph sorter, entity dirty checker, queue builder, queue processor, query builder and query execution engine all have to work together properly, and, in such a way that the output of a previous unit is the input of another unit.

This is a fundamental difference with a unittest and therefore the analogy is silly: with an integration test, the units get input from another unit in a context described by the integration test, but not by an individual test. An integration test could test a lot of different scenario's where it would be impossible to test the individual units separately, because the # of different situations the units would occur in would be very high and therefore also the # of required unittests to test the individual unit, namely 1 for every situation (input + application state when the unittest starts)

But, you don't have to listen to me, Derik. If you think integration testing is about figuring things out instead of checking if things work or not, so be it. But keep in mind that one shouldn't fall for the myth that IF all unittests run, it would automatically mean that , when used together, the units also work together, because that's not the focus of unittesting, nor should such a conclusion be drawn from running unittests.

I too, have to disagree about the analogy.

A better analogy is a production line (think about building a car). A unit test is making sure each guy (or girl or robot) does *their* job properly.

An integration test is making sure at the end of the line you get a car that works. Because and integration test is the sum of the parts, you are just making sure the sum is correct.

I think that this question very specific and will correspond to each person and separateness, showing its character and manners.

Nice, liked it!

As with most analogies, it tends to fall apart when you pick at it to much; but as a quick way to describe to someone in readily-understood terms, I think it's a corker. After all, who hasn't spent at least 10 minutes with friends going over the bill trying to work out who had the $25 steak and how to divide up the $40 bottle of wine that we all ordered but some had two or three glasses of while others only had one? And who hasn't spent at least 10 minutes trying to figure out why an integration test, whether it was because the business logic is broken, or you're missing some setup data you didn't realise needed to exist?

i think it's a good analogy but you can expand by changing this bit:

"sometimes everyone things they are good, but in the end the total amount may be too high or too low"

to something like this:

"sometimes, very rarely, the total amount is correct and everyone is happy.

"But more often than not the total is incorrect -- and then all hell breaks loose. A small number of people re-check their own total, but most of the people start re-checking everyone else's total. They all disagree about everything and finally, one person agrees to put in extra money (even when they've already paid enough) just to stop everyone else from fighting. The interdependencies are complex, time wasting, and ultimately: social death!"

cheers

lb

BAD analogy... Try buffet: UT is like eating one entry... (e.g. potatos) Integration Test is like combination of enties on your plate (like potatoes & gravey) :)

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #105

I actually agree with Frans on this one. And, to nitpick, the integration testing doesn't require the couples to know dependencies - it just requires the server to verify that the total amount is correct (based on each particular couple doing their job correctly - paying their own portion). At least, I think that's where the analogy is going.

Based on the title, I was thinking more along the lines of Unit Testing: testing each ingredient (Is the lettuce crisp, fresh, and clean? Are the tomatoes red, ripe, and juicy? Etc.), and Integration Testing: Once I put the verified ingredients together, do they taste good *together*? Are they in the right proportions? Etc.

Oh. I thought this was going to be unit testing = tasting each dish in the kitchen / integration testing = what happens at the tables (the whole experience).

Is the analogy between tasting and testing of any help to people?

The reason I don't care for this analogy is that it implies that if you do unit testing, that's all you need and you can go home. But in reality there are plenty of things that may only be caught by integration testing. You need both.

How about this. No tests at all are like asking everyone to pay whatever they think. Unit tests are like showing each person what they ordered and the cost (plus tax and tip) and asking them to verify their intended contribution. But the integration tests are needed to make sure you collect enough to cover all the bottles of wine and seafood appetizers that everyone shared, being sure of course to discount the vegetarians and non-drinkers in the group. If I do the unit tests first, it will surely make the integration tests go more smoothly, but I had better still do the integration tests if I don't want to get stuck washing dishes!

I, too, thought it would be about tasting - how ginger chicken tastes great on it's own but when paired with garlic brussel sprouts (also flavorful on their own) the two compete and don't mesh well.

Grins,

I think the analog works because the time it takes to settle the build.  When you ahve  independent unit testing, developers can run these test in few minutes at worst versus intergration testing which takes a lot longer and requires reintitialize configurations to work. Does each developer have to have there own testing area or are we experiencing a bottleneck at checkin?  

I agree that integration is needed but I hope that this can be done less often in a more pristine environment.

Good Example.