Add support for test, class and database level setup and teardown

[bartread]

It would be helpful to have setup and tear-down mechanisms, as per NUnit and the like. These could be used at the test, class , or database level to initialise any pre-requisite data, and get rid of it afterwards.

[mbt1]

There is a class level setup already. Just create a procedure [TestClassName].[setup] and it will be executed before each test. You don't need a teardown, as every test is executed in a transaction that is rolled back after execution. I don't like the idea of setup procedures (particularly on the database or single test level), as it effectively hides test code. Instead I recommend to create an explicit setup procedure with a telling name and call that from within your tests. That way, when looking at each test, there is no question about what is happening. Also, that way you can chose to skip that call in a test that needs something else. In my experience there is always one in each test class. Besides that, I don't see a way to implement a database level setup process, as the entire structure of tSQLt is based on the concept of test classes.

[TheConstructor]

@mbt1 I don't know what @bartread had in mind, but we would like to exclude the setup-instructions from the time measures as test-duration. We also thought about using tear-down to store statistics about the test-run.

If you want to test procedures accessing files or executing statements on remote servers there also may be a real need for tear-down.

[mikebeaton]

I'm not sure if it is worth commenting on a closed issue, but I was just wondering what about the case of testing code which is designed to work cross-database? In that case, you might like to be able to set up some new (test) databases in SetUp and then remove them in TearDown? (And I believe I'm right that this is something that can't be rolled back by a transaction.)

[mbt1]

Interesting Idea. You're correct, CREATE DATABASE, as well as DROP DATABASE, cannot be executed within a transaction. There's also the idea of a "per run"-setup/teardown, instead of a "per test", as it is usually handled - particularly for things like creating/dropping databases.

I'll reopen this for now, but it will need some more thought.