How to start automated testing a large application?

EDIT : Thanks to the ncie commenters, I get the difference between unit and automated testing, so I renamed the topi开发者_JS百科c

Environement : .net 2.0, sql server 2005,windows server 2003

I read this article :

http://www.codeproject.com/KB/tips/convince.aspx

This guy is speaking about how you can add automated testing to an existing app without changng everything.

And I have to say that this article is really awesome, and make me wanna try it !

So our system is nearly the same : all the datas are accessible through web services, so we can easily (with soapui for instance) do some automated testing against these web servcies.

BUT : what about the database ? To do some automated testing, we need to have the correct data in the database corresponding to the automated test.

For instance, if I want to do a automated test checking that the software raises an error if the client's name is empty, I'll need to add, in my db, a client with an empty name.

here is how I think I can do it :

• create a server with everything it needs (iis, sql server...)
• add something so the date of this server never change so I don't have to change the time in my automated test
• add in my database the records I need to do my automated test

PROBLEM : the database will be a big mess in after 10 automated test, and I'll never know which record is for which automated test. The idea would be to add a "TEST_NAME" column to every table, but it's a bit dirty in my mind.

So have you ever tried that kind of technique ? Did you use some specific tools ? Is my way of thinking the good one ? (or at least a good one).

Thanks

EDIT : I got 2 -1 for this thread, I'd like to know why so I won't do the same mistake twice.

---

If your unit tests are hitting your persistence layer you may actually be doing something akin to integration testing. What you should do it abstract your database away during the unit test so that you are only test the logic and not that actually persistence medium. This allows you to focus on the business layer logic. This is easier said than done since it depends on the architecture of your data layer.

Data layers are often a simple matter of push in and pull out so lets say you can abtract your data layer into an interface like:

interface IRepository
{
   GetModel(id);
   SaveModel(model);
}

Then in your unit test to can stub/mock out your data layer with this interface. This way you tell the stub of your database to return any value you want and you can write a test that assets the expected behavior when that happens.

---

There maybe better solution than the one I am thinking about, but why not use a different database for unit testing and purge all content in preparation of another test cycle.

---

If you can generate your test data before each batch of tests then have your records start at an ID equal to the next number divisible by 100. So if the largest record is 350, generate starting a 400 and test with 400 and above. When your DB gets really big, delete every thing.