How to do integrated testing?

Question

So I have been reading up on a lot of books surrounding testing. But all the books I've read have the same flaws. They will all tell you the definitions of testing. But I have not found a single book that will guide you into integration testing (or pretty much anything higher then unit testing). Is integration testing that elusive or am I reading the wrong books?

I'm a hands on person, so I would appreciate it if someone could help me with a simple program:

Let's say you need to make some sort of calculation program that calculates something (doesn't matter what) and exports it to *.txt file. Let's assume we use the Model View Controller design principle. And one class for the actual calculating which you'll use in the model and one for writing the textfile. So:

View => Controller => Model => CalculationClass, FileClass

So for unittesting: You'd test the calculationClass, I'd personally focus most of my unit tests there. And less time on unit testing the view/controller/FileClass. I personally wouldn't see the use of unittesting those unless you want a really robust program.

Integration testing: Now this is where I run into a wall. What would I have to test to call it an integration test? I could stub the view and feed the controller data which it would pass on to the model and so forth. And then check what the view gets back in the end. But ... Couldn't I just run the (in this case small) program then and test it manually? Would this be considered a integration test too, or does it have to be automated? Also, can I check multiple items to see if they are correct?

I cannot seem to find any book that offers a hands on approach to methods of integration testing.

Answer 1

Couldn't I just run the (in this case small) program then and test it manually?

Yes, that can be considered to be an integration test. The question is how often do you expect that test to be repeated, and how much effort will it take to automate the process. If you think that test needs 5 minutes, and automating it takes 5 days, then you can make a lot of manual tests before it pays to write an automatic test. On the other hand, in a real scenario, you will often have to test a lot of more processes, each process will take more than 5 minutes to test, and you will have a framework like FitNesse helping you writing integration tests faster. The former link leads also to a book.

Answer 2

You could try Lisa Crispins book on Agile Testing, that goes through a lot of the testing types. She also has a lot on her blog - try this one agile testing quadrants

Answer 3

To give you an example, on my last project, our integration tests ran like a story across a set of services all the way down to the database layer.

We had a service method that created something and one that read it back out by ID.

So one integration tests calls the service method to create, then read it back using the Get service method and compare data. That's the basic idea anyway, we had lots of longer "stories".

For each integration test we tore down and rebuilt the DB from scratch including static data.

Answer 4

Integration testing: Now this is where I run into a wall. What would I have to test to call it an integration test?

Integration testing is a tricky thing indeed. The most comprehensive definition is offered by ISTQB. Integration testing there is split into 2 subtypes:

• component integration testing that tests the interconnections between various software components
• system integration testing that tests interactions of your product with external systems.

Here is an example that may help you clear this up. The example also shows that integration testing automation works well when the product uses large volume of repeatable or predictable data. In other cases, manual testing may make a good alternative.The main point here is to know the way the systems are supposed to work and describe all possible interactions.