One of the great features of Visual Studio 2008 is the ability to test Web applications using Web Tests. Web Tests allow you to record a user's path through a running Web application and turn these actions into an automated test that Visual Studio can later run against subsequent builds of your application. They're immensely helpful for quickly validating Web application builds to see if your application is working properly. The idea is that you record your use cases as Web Tests and then Visual Studio can QA your application for you. This eliminates a lot of tedious manual testing and can greatly speed up your testing cycles.In order to create a Web Test, you use a browser and the Web Test Recorder plug-in to record yourself clicking through the application. When you click the stop button, Visual Studio has recorded everything you just did as a Web Test. Once you've recorded the basic structure of your web tests, you can then add Validation Rules and Extraction Rules to build up more intense and rigorous tests.
Figure 1. Creating a Web Test using the Web Test Recorder
Figure 2. A recorded Web Test in Visual Studio
Figure 3. The results from the run of a Web TestSo, let's assume that you're using Web tests to validate your application. Your typical interaction might be to come in to work in the morning, do a Get Latest, compile the code, then run all your unit tests, and then run all your web tests. If everything passes, you know that your application is working and that it's "safe" to start implementing more features. Not a bad way to work but let's say that you have a continuous integration (CI) build running via TFS Team Build. You probably have all your unit tests running as part of this CI build. Every time someone checks in code, the CI build runs, compiles your code, and runs your unit tests. This gives you immediate feedback about whether the code is broken. The unit tests you run as part of the CI build tend to do tests at a fairly low level in the code – checking method-level operations. It would be nice to get this kind of feedback from your CI builds at a higher level and know about how the Web application is running. It's time to run your Web tests as part of the build. Right now, your TFS build script (TFSBuild.proj) probably has a line in it to run your unit tests that looks something like this:
This line tells the build process to look for any DLLs in the build output directory where the filename ends with *.UnitTests.dll. Any matching file will be run as a unit test assembly. Recorded Web Tests work differently – rather than being part of a compiled assembly, they're actually XML scripts.
Figure 4. Web Test XMLThis means that the test runner references them differently and that they are treated differently by the build. When the build runs, any web test files (*.webtest) get copied to the build output directory.
Figure 5. *.webtest in the Build Output DirectoryIn order to make your Web tests run as part of your build, you have to add an additional
Figure 6. Add a TestContainer directive for the Web testsIf you add the directive as shown in Figure 6, check in your TFSBuild.proj build script, and run your build, you'll now see that your Web tests are executing as part of the build. A simple fix.