views:

538

answers:

6

I am introducing automated integration testing to a mature application that until now has only been manually tested.

The app is Windows based and talks to a MySQL database.

What is the best way (including details of any tools recommended) to keep tests independent of each other in terms of the database transactions that will occur?

(Modifications to the app source for this particular purpose are not an option.)

+1  A: 

You can dump/restore the database for each test suite, etc. Since you are automating this, it may be something in the setup/teardown functionality.

Kris Kumler
A: 

The best environment for such testing, I believe, is VMWare or an equivalent. Set up your database, transaction log and so on, then record the whole lot - database as well as configuration. Then to re-test, reload the image and database and kick off the tests. This still requires maintenance of the tests as the system changes, but at least the tests are repeatable, which is one of your greatest challenges in integration testing.

For test automation, many people use Perl, but we've found that Perl programs grow like Topsy and become convoluted. The use of Python as a scripting language (we run C++ tests) is worthwhile if you're trying to build a series of structured tests.

Doug Scott
A: 

As @Kris K. says dumping and restoring the database between each test will probably be the way to go.

Since you are looking at doing testing external to the App I would look to build the testing framework in a language where you can take advantage of better testing tools.

If you built the testing framework in Java you could take advantage of JUnit and potentially even something like FitNesse.

Don't think that just because the application under test is C++ that means you are stuck using C++ for your automated testing.

Bradley Harris
+1  A: 

I used to restore the database in the SetUp function of the database related unit test class. This way it was ensured that each test runs under the same conditions.

You may consider to prepare special database content for the tests, i.e. with less data than the current production version (to keep the restore times reasonable).

Fabian
+2  A: 

How are you verifying the results?

If you need to query the DB (and it sounds like you probably do) for results then I agree with Kris K, except I would endeavor to rebuild the DB after every test case, not just every suite.

This helps avoid dangerous interacting tests

As for tools, I would recommend CppUnit. You aren't really doing unit tests, but it shouldn't matter as the xUnit framework should give you the set up and teardown framework you'll need to automatically set up your test fixture

Obviously this can result in slow-running tests, depending on your database size, population etc. You may be able to attach/detach databases rather than dropping/rebuilding.

If you're interested in further research, check out XUnit Test Patterns. It's a fine book and a good website for this kind of thing.

And thanks for automating :)

Nick

Nick Monkman
A: 

Please try AnyDbTest, I think it is the very tool you are finding. (www.anydbtest.com).

Features:

  • 1.Writing test case with Xml, not Java/C++/C#/VB code. Not need those expensive programming tools.

  • 2.Supports all popular databases, such as Oracle/SQL Server/My SQL

  • 3.So many kinds of assertion supported, such as StrictEqual, SetEqual, IsSupersetOf, Overlaps, and RecordCountEqual etc. Plus, most of assertions can prefix logic not operator.

  • 4.Allows using an Excel spreadsheet/Xml as the source of the data for the tests. As you know, Excel spreadsheet is to easily create/edit and maintain the test data.

  • 5.Supports sandbox test model, if one test will be done in sandbox, all database operations on each DB will be rolled back meaning any changes will be undone.

  • 6.Allows performing data pump from one database/Excel into target database in testing initialization and finalization phase. This is easy way to prepare the test data for testing.

  • 7.Unique cross-different-type-database testing, which means target and reference result set can come from two databases, even one is SQL Server, another is Oracle.

  • 8.Set style comparison for recordset. AnyDbTest will tell you what is the intersection, or surplus or absence between the two record sets.

  • 9.Sequential style comparison for recordset or scalar values. It means the two result set will be compared in their original sequence.

  • 10.Allow to export result set of SQL statement into Xml/Excel file.