CODEWITHSUNDEEP
c#testingintegration-testing
alice7
alice7

Reputation: 3880

Writing Integration tests to test database, web service calls

We are just starting to write integration tests to test database,data access layer, webservice calls etc. Currently I have some idea to write integration tests like 1) Always recreating tables in initialize function. 2) Always clear the data inside a function, if you are saving new inside the same function.

But I would like to know some more good practices.

Upvotes: 5

Views: 2000

Answers (3)

dolphy
dolphy

Reputation: 472

When unit testing the DAL, I do it like this:

[TestFixtureSetUp]
public void TestFixtureSetUp()
{

    //this grabs the data from the database using an XSD file to map the schema
    //and saves it as xml (backup.xml)
    DatabaseFixtureSetUp();  
}

[SetUp]
public void SetUp()
{

    //this inserts test data into the database from xml (testdata.xml)
    //it clears the tables first so you have fresh data before every test. 
    DatabaseSetUp();  
}

[TestFixtureTearDown]
public void TestFixtureTearDown()
{
     //this clears the table and inserts the backup data into the database
     //to return it to the state it was before running the tests.
    DatabaseFixtureTearDown();
}

Upvotes: 1

Rich O'Kelly
Rich O'Kelly

Reputation: 41767

As with all testing, it is imperative to start from a known state, and upon test completion, clear down to a clean state.

Also, test code often gets overlooked as not real code and hence not maintained properly... it is more important than code. At least as much design, should go into the architecture of your tests. Plan reasonable levels of abstraction, ie if you are testing a web app, consider having tiers like so: an abstraction of your browser interaction, an abstraction of your components on pages, an abstraction of pages and your tests. Tests interact with pages and components, pages interact with components, components interact with the browser interaction tier and the browser interaction tier interacts with your (possibly third party) browser automation library.

If your test code is not maintained properly or well-thought out, they become a hindrance more than an aid to writing new code.

If your team is new to testing, there are many coding katas out there that aim to teach the importance of good tests (and out of this comes good code), they generally focus on a unit testing level, however many of the principals are the same.

Upvotes: 5

neontapir
neontapir

Reputation: 4736

In general, I would suggest you look into mocking your database access layer and web service call classes in order to make it more testable. There are lots of books on this subject, like Osherove's The Art of Unit Testing.

That having been said, integration tests should be repeatable. Thus, I would choose option 1, to write a script that can recreate the database from scratch with test data. Option 2 is more difficult, because it can hard to be sure that the cleaning function does not leave unwanted data residue.

Upvotes: 2

Related Questions