Learn How - Object Change Notifications and Automated Unit Testing

1. Be sure you've installed SQL-Hero server components. The document to consult on this one can be found here. Double check that you have a server name specified on the Settings tool:

Also be sure the SQL-Hero Windows Service is running:

Furthermore, this assumes you've previously set up some global connections as described here.

2. Let's set up object change tracking first. If you followed the steps outlined here, then you've already added change tracking to one or more databases. The next requirement is to add a notification around this. Go to the Notifications tool, click on "New":

3. Configure the notification to look something like this:

Here we've restricted to a specific database (RDDev) and are sending to all users with email addresses set, as described here. 4. Click on the Configure button next to the Delivery Type(s) - this is necessary to supply the SMTP mail server name:

5. To illustrate other possibilities, click on the Configure button next to Events - if the event type has any parameters that is supports, you can set them now. The object changes type allows you to optionally specify a comma separated list of object types that will be used to filter the reporting. (The type codes are the standard codes that SQL Server recognizes - e.g. "U" for tables, "P" for stored procedures, etc.)

6. Let's now set up scheduled SQL unit testing. Go to the Testing tool and click the "Schedules" button:

7. Provide information in the available "new schedule" row:

In this example we're saying that we want to apply testing against the RDDev database every 15 minutes, using three different types of test cases: "select from" testing, "null run parameter" testing and "test run parameter" testing. More detail on what this means can be found here. If "Errors" were checked, we'd only record failures associated with the test, as opposed to both successful completions and failures. There are optional name filtering fields (which act as regular expressions), plus the ability to filter based on only applying testing to objects changed since a specific date. The "Test Timeout" field lets you override the global test timeout setting - this is used to stop tests that take "too long". The "Create Test Tries" field is very important: if it is not filled in, only existing tests are run against objects. If it is filled in with a number, then objects that do not have test cases defined will have attempts made to generate a test case. The number of attempts that will be made is what is specified here. The global testing policy file will be used to generate those tests.

Once you've saved this test schedule, as you refresh this screen, you'll see the status of the schedule item change:

... and eventually you'll see the actual tests being run - in this example, a specific procedure is being exercised - the screen offers the ability to kill the running test, as well: