One of the features that sets 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 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.

Need to take a step back? Learn to set up a testing project in LegiTest >

Make A Test Data-Driven in LegiTest

1. To accomplish this, I went into my tests and then into the Data-Driven Source and clicked the box: Enable data-driven testing for this test.

2. Give it a connection – I used my HigherEd connection. This can be sourced from any ADO.NET compatible data source or any of the other available data connections.

3. In this case, rather than pulling the data, I am going to use a select statement that effectively hard-codes the values in. In my case, I know what my values are as seen in the select statement for each of the states. I’ve also included a bad value in the form of Florida, for which I have 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.

4. To verify everything, click Execute. Down at the bottom, I can see my 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.

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 {{the name of the resource key}}. 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.

6. Now I have the stored procedure being executed with various states. Another thing I want to do is change my assertion since I don’t want every state to be compared with the static value 433. I’m going to change the Comparable value source to a Resource, and pick a resource for it. I can see both the ExpectedStudentCount and State. Since we’ve already used the State, we’ll use the ExpectedStudentCount as the resource.

7. Save your test. Go to Build -> Build Solution. Now run your tests in the Test Explorer. For this scenario, I am expecting a failure because of the Florida value. Once I see a failure, I 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.

8. Keep in mind, if you are using NUnit, the results will show up differently.

9. To fix the error, I can go back into my Data-Driven Source and edit my information so 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.

To help you get the most of your experience with LegiTest, we’re building a comprehensive library of LegiTest video walkthroughs and step-by-step tutorials.

Explore the LegiTest Library

Share This