OK, the further I go with this the more needs doing (is that not always the way).
So here is where we got this morning. I was replacing all the If @@ERROR <> 0 with TRY/CATCH when I noticed some weird behavior.
The Suite setup and tear down were being called before each test in the suite, not at the start and end of the suite (respectively) and that the procedure that built the list of tests to be executed explicitely checked for the _Setup and _teardown on the suites.
Well that struck me as dumb ... so change the Cursor Select statement to exclude stored procs in the unitTest Schema if they end in '_Setup' or '_TearDown' ... and then just treat all the rest of the stored procs as tests to be executed ... much easier ...
Then on to the procedure that actually executes the tests in a suite ...
Before starting on the tests in now does the following ... (the name of the Suite is passed to it when it is called as @suite)
if there is a stored proc called @suite_Setup run it.
For each test in the suite
- If there is a stored proc called @testName_Setup run it
- Run the test
- If there is a stored proc called @testName_TearDown run it
Next Test
If there is a stored proc call @suite_TearDown run it
Much better logic and removes lots of strig checks and stuff from the generation of the list of tests.
It was also coded to take into account a couple of issues with the way errors were handled in SQL 2000 (or in some cases not handled). So there was lots of rollbacks and other stuff and tables to store stuff if stuff broke because the error trapping might not work. Well error trapping is now lots better and most of this is no longer needed ... so I have begun to week this out. It is a big job as it is embedded all through the structure ... but I am getting there.
So here is where we got this morning. I was replacing all the If @@ERROR <> 0 with TRY/CATCH when I noticed some weird behavior.
The Suite setup and tear down were being called before each test in the suite, not at the start and end of the suite (respectively) and that the procedure that built the list of tests to be executed explicitely checked for the _Setup and _teardown on the suites.
Well that struck me as dumb ... so change the Cursor Select statement to exclude stored procs in the unitTest Schema if they end in '_Setup' or '_TearDown' ... and then just treat all the rest of the stored procs as tests to be executed ... much easier ...
Then on to the procedure that actually executes the tests in a suite ...
Before starting on the tests in now does the following ... (the name of the Suite is passed to it when it is called as @suite)
if there is a stored proc called @suite_Setup run it.
For each test in the suite
- If there is a stored proc called @testName_Setup run it
- Run the test
- If there is a stored proc called @testName_TearDown run it
Next Test
If there is a stored proc call @suite_TearDown run it
Much better logic and removes lots of strig checks and stuff from the generation of the list of tests.
It was also coded to take into account a couple of issues with the way errors were handled in SQL 2000 (or in some cases not handled). So there was lots of rollbacks and other stuff and tables to store stuff if stuff broke because the error trapping might not work. Well error trapping is now lots better and most of this is no longer needed ... so I have begun to week this out. It is a big job as it is embedded all through the structure ... but I am getting there.
- Music:Weird Al- Yankovic - Pretty Fly For A Rabbi


Comments
These are interesting posts, because I've never thought about unit testing a database. I guess it makes sense for CCP, with all the use of stored procedures. We don't use any here at Mozilla or at my previous gigs (sans CCP of course) so it's neat.