20.4. Testing Context
When you are writing test cases, the testing engine can assist you in a number of ways, including by managing sets of data so you can run a test case with a range of data, and by enabling you to output additional information for the test case to aid in debugging. This functionality is available through the TestContext object that is generated within a test class.
20.4.1. Data
The CurrentStatusTest method generated in the first section of this chapter tested only a single path through the CurrentStatus property. To fully test this method, you could have written additional statements and assertions to set up and test the Subscription object. However, this process is fairly repetitive and would need to be updated if you ever changed the structure of the CurrentStatus property. An alternative is to provide a DataSource for the CurrentStatusTest method whereby each row of data tests a different path through the property. To add appropriate data to this method, use the following process:
Create a local database and database table to store the various test data. In this case, create a database called LoadTest with a table called Subscription_CurrentStatus. The table has an Identity column called Id, a nullable DateTime column called PaidUp, and an nvarchar(20) column called Status.
Add appropriate data values to the table to cover all paths through the code. Test values for the CurrentStatus property are shown in Figure 20-6.
Figure 20.6. Figure 20-6
Use the Connection Properties dialog to connect to the database created in Step 1. You should see a connection string similar to the following:
Data Source=localhost;Initial Catalog=LoadTest;Integrated Security=True
If the connection string is valid, a drop-down box appears when you select the DataTable property, enabling you to select the database table you created in Step 1.
To open the test case in the main window, return to the Test View window and select Open Test from the right-click context menu for the test case. Notice that a DataSource attribute has been added to the test case. This attribute is used by the testing engine to load the appropriate data from the specified table. This data is then exposed to the test case through the TestContext object.
Modify the test case to access data from the TestContext object and use the data to drive the test case, which gives you the following CurrentStatusTest method:
<DataSource("System.Data.SqlClient", "Data Source=localhost; Initial Catalog=LoadTest;Integrated Security=True", "Subscription_CurrentStatus", DataAccessMethod.Sequential)> _ <TestMethod()> _ Public Sub CurrentStatusTest() Dim target As Subscription = New Subscription If Not IsDBNull(Me.TestContext.DataRow.Item("PaidUp")) Then target.PaidUpTo = CType(Me.TestContext.DataRow.Item("PaidUp"), Date) End If Dim val As Subscription.Status = _ CType([Enum].Parse(GetType(Subscription.Status), _ CStr(Me.TestContext.DataRow.Item("Status"))), Subscription.Status) Assert.AreEqual(val, target.CurrentStatus, _ "Subscription.CurrentStatus was not set correctly.") End Sub
When this test case is executed, the CurrentStatusTest method is executed four times (once for each row of data in the database table). Each time it is executed, a DataRow object is retrieved and exposed to the test method via the TestContext.DataRow property. If the logic within the CurrentStatus property changes, you can add a new row to the Subscription_CurrentStatus to test any code paths that may have been created.
Before moving on, take one last look at the DataSource attribute that was applied to the CurrentStatusTest. This attribute takes four arguments, the first three of which are used to determine which DataTable needs to be extracted. The remaining argument is a DataAccessMethod enumeration, which determines the order in which rows are returned from the DataTable. By default, this is Sequential, but it can be changed to Random so the order is different every time the test is run. This is particularly important when the data is representative of end user data but does not have to be processed in any particular order.
20.4.2. Writing Test Output
Writing unit tests is all about automating the process of testing an application. Because of this, these test cases can be executed as part of a build process, perhaps even on a remote computer. This means that the normal output windows, such as the console, are not a suitable place for outputting test-related information. Clearly, you also don't want test-related information interspersed throughout the debugging or trace information being generated by the application. For this reason, there is a separate channel for writing test-related information so it can be viewed alongside the test results.
The TestContext object exposes a WriteLine method that takes a String and a series of String.Format arguments that can be used to output information to the results for a particular test. For example, adding the following line to the CurrentStatusTest method generates additional information with the test results:
TestContext.WriteLine("No exceptions thrown for test id {0}", _
CInt(Me.TestContext.DataRow.Item(0)))After the test run is completed, the Test Results window will be displayed, listing all the test cases that were executed in the test run along with their results. The Test Results Details window, shown in Figure 20-7, displays any additional information that was outputted by the test case. You can view this window by double-clicking the test case in the Test Results window.
Figure 20.7. Figure 20-7
In Figure 20-7, you can see in the Additional Information section the output from the WriteLine method you added to the test method. Although you added only one line to the test method, the WriteLine method was executed for each row in the database table. The Data Driven Test Results section of Figure 20-7 provides more information about each of the test passes, with a row for each row in the table. Your results may differ from those shown in Figure 20-7, depending on the code you have in your Subscription class.