Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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.

share|improve this question
    
I've made the exact same topic over there now. Thanks so much! –  Enthusiastic Programmer Apr 3 '12 at 11:37
3  
Please don't cross post. If you want, the question could be migrated. –  ChrisF Apr 3 '12 at 11:44
1  
@ChrisF This would fit well over at SQA.SE, the cross-post has also gathered answers now. I guess if this is migrated, we can merge the questions. –  testerab Apr 3 '12 at 18:54
    
Welcome to SQA, Enthusiastic Programmer. It may help to read this: sqa.stackexchange.com/questions/2599/… –  user246 Apr 3 '12 at 19:42
    
Thanks for the flags @ckenst user246 and others - the dupe was temporary and deliberate, I asked Prog.SE to migrate the question so we could merge them here, rather than have questions duplicated across sites. Generally considered better to migrate questions to the right home rather than to cross-post, apologies for any confusion in the interim. –  testerab Apr 4 '12 at 19:59
add comment

migrated from programmers.stackexchange.com Apr 3 '12 at 18:59

This question came from our site for professional programmers interested in conceptual questions about software development.

3 Answers

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

share|improve this answer
    
can I trouble you to move this comment to sqa.stackexchange.com/questions/2958/…? –  user246 Apr 4 '12 at 12:07
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.