This is a very powerful tool, where we can ask consultants and users to create the test cases based on what they expect for the developer to use as a test case.

Although there is a lot going on behind the scenes, it works by reading the XML file created by the task recording. When each step is recording, the system stores the information about the form and controls in a way that can be referenced in code. The task recoding import creates a class that uses the form adaptor in order to interact with the form programmatically, using the steps in the XML file.

Although this code is generated, we can edit it. In the case of validations, we usually have to. For example, the consultants could have added a validation for the item name. Since we can only use the current value to validate against, we will need to amend the code. In the case of an item name, we would write code to find the expected value based on the item ID the user entered.

Since these tests can be automated at the build server, the data used to create the test case and that on the build server itself must be the same. This is done by importing a backup of the database from the test database. With the technique described in this recipe we can then create integration tests that are run automatically on every build, this is much more robust that relying solely on end-user testing. It is natural for us to test what has changed, and therefore very easy to miss regression in areas that haven't been changed. The task recording is no more effort that the testing the users would have to do anyway, and with a relatively small development effort we have a repeatable set of tests that will always run, regardless of the change made in the build.