MSTest unit tests and database access without touching the actual database -


in code interact database (not part of solution file). database owned separate team of dba's, , code developers write allowed access stored procs. have full view of database's procs, tables, , columns (it's definition). code dependent upon data, write unit tests dumb-up data in tables (and tear down/remove rows after unit test done), can run unit tests exercise code interacts db. of code in test file (especially in classinitialize() , classcleanup() functions). i've been given amount of grief new coworkers call style of unit tests "destructive" because read/write dev database inserting , removing rows. @ time code unit tests, database design not stable, many times can find issues in stored proc code before unleash qa department on our programs (saves resources). tell me there's way clone database memory @ time mstest unit tests run, don't know how it. i've researched around web , cannot find way coworkers need me do.

can tell me sure whether or not can happen in environment shown above? if so, can point me in right direction?

do have sql scripts can used create database? should have, , should under version control. if so, can following:

in test setup code:

  • create 'temporary' database using sql scripts. use unique name, example unittestdatabase_[timestamp].
  • setup data require test in test database. ideally using public api functions (eg createuser, addnewcustomer), required api not exist, use sql commands. using api set test data makes tests more robust against changes low-level implementation (i.e. database schema). 1 reason why write unit tests, ensure changes implementation not break functionality.
  • run unit tests, using dependency injection pass test database connection string test code code under test.

and in test teardown code, delete database. ideally should done using database uninstall scripts, should under version control.

you can control how want create unit test database: e.g. per test project, test class or test method, or combination, creating database in either [assemblyinitialize], [classinitialize] or [testinitialize] method.

this technique use great success. advantages are:

  • every time run unit tests, testing our database installation scripts work code.
  • test isolation, tests affect test database. , doesn't matter if rollback code goes wrong, not touching else's data.
  • confidence in code. is, because using real database, unit tests give me more confidence code works if mocking database. of course, depends on how suite of higher level integration/component tests are.

disadvantages:

  • the unit tests dependant on external system (the dbms). need find name of dbms in test setup code. can done using config file or looking @ run time running local dbms.
  • tests may slowed down database installation scripts. in our experience, tests still running enough, , there plenty of opportunities optimize. run our test suite of approx 400 unit tests in approx 1 min, includes creating 5 separate database on local installation of sqlserver 2008.

Comments

Popular posts from this blog

android - Spacing between the stars of a rating bar? -

aspxgridview - Devexpress grid - header filter does not work if column is initially hidden -

c# - How to execute a particular part of code asynchronously in a class -