One of the features that sets SentryOne LegiTest apart is support for data-driven testing. This feature gives you the ability to create a test case once and execute it multiple times over a large number of test scenarios using input data from a variety of sources (including any ADO.NET source, SalesForce or REST Web Sources). LegiTest’s dynamic parameterization reduces coding time and allows for greater productivity and efficiency.
The latest video in our series shared step-by-step instructions for how to make your test dynamic so that you can reuse test logic for common scenarios. This example uses a test that executes a stored procedure to get the student count. It has a number of states to test and to ensure the stored procedure is working correctly with all the states, it needs to be turned into a data-driven test. Data-driven tests allow you to set up your test logic once and execute it many times with different combinations and permutations of the data.
Step 1: To accomplish this, go into your tests and then into the Data-Driven Source and selected the box Enable data-driven testing for this test.
Step 2: Give it a connection – this example used my HigherEd connection. This can be sourced from any ADO.NET compatible data source or any of the other available data connections.
Step 3: In this case, rather than pulling the data, this example uses a select statement that effectively hard-codes the values in. In this case, we know what the values are as seen in the select statement for each of the states. We’ve also included a bad value in the form of Florida, for which there are two select statements (375 is the correct number, while 400 is the bad number). This will show you what a failure in a data-driven test looks like.
Step 4: To verify everything, click Execute. Down at the bottom, you can see the State and Expected Student Count, and their values beneath it. These column headers become available resources we can use within our test. The test will be executed once for each row.
Step 5: We want to update the test and actually use these values so that the test is parameterized and changes for each row are being executed. Now I’ll go back to my student count procedure and make this hard coded value, New York, data-driven. I can modify this by typing in . In my case, the resource key would be state, which matches the column header from a few steps ago. Anywhere you use this syntax, it will be replaced dynamically at runtime within the queries and other places within LegiTest.
Step 6: Now we have the stored procedure being executed with various states. Another thing we want to do is change the assertion since we don’t want every state to be compared with the static value 433. We will change the Comparable value source to a Resource, and pick a resource for it. You can see both the ExpectedStudentCount and State. Since we’ve already used the State, we’ll use the ExpectedStudentCount as the resource.
Step 7: Save your test. Go to Build -> Build Solution. Now run your tests in the Test Explorer. For this scenario, we are expecting a failure because of the Florida value. Once we see a failure, we can look into the details of it and see the expected value was 400 and the actual value was 375. To see more detail, I click Output and see exactly what test parameters were put in. You can also see the tests that passed if you scroll down past the failure.
Step 8: Keep in mind, if you are using NUnit, the results will show up differently.
Step 9: To fix the error, we can go back into the Data-Driven Source and edit the information so that it’s correct. Then click Execute and go back into the Test Explorer and click Run All. This time all of the tests should pass.