Introduction
Testing applications is the last step in the software development cycle before implementation. Today, I will speak about trace testing and the tools available for Visual Studio.
Testing
Obviously, testing your applications is a very important, if not the most important, part of the software development process. Debugging goes hand in hand with testing, but there are many facets to testing than just testing the application. Testing can be broken into the following categories:
- Stress testing
- Load testing
- User testing
Stress Testing
Stress testing involves testing an app to its limits. This usually involves more than one user using the application and literally trying to break the application. More information about stress testing can be found at this link: stress testing.
Load Testing
Load testing involves testing your applications’ performance. The Load refers to the “load of data,” so to speak. When your application becomes slow or is generally slow, there is a definite problem. This problem might be because of the database code itself—which can be a long SQL query that executes slowly. You can either optimize the code, or use performance monitoring tools to ascertain the exact problems. Here is more information on Load Testing. I will speak about performance testing a little bit later.
User Testing
As the name implies, User testing involves the users of your application. Usually, testers will test the functionality of the program and simply use it. By having several users using your app (before it gets implemented), you can stumble upon errors and you can fix them before the final product ships. For more information on User testing, have a look at this link: User testing.
Setting Up a Test Environment
Before I move onto Trace testing, let me just make sure that you know how to set up a test environment in Visual Studio. If you have Visual Studio Ultimate, you should have noticed a menu item named TEST, as shown in Figure 1:
Figure 1: The TEST Menu
To set up a test environment, you need to set up unit testing via a test settings file. Follow these steps:
- Add an XML file to your solution and rename it test.runsettings, for example. If you do not know what an XML file looks like, have a look at XML Files.
- Edit the file to look like the following:
<?xml version="1.0" encoding="utf-8"?> <RunSettings> <RunConfiguration> <ResultsDirectory>.\TestResults</ResultsDirectory> <TargetPlatform>x86</TargetPlatform> <TargetFrameworkVersion>Framework40</TargetFrameworkVersion> </RunConfiguration> <MSTest> <MapInconclusiveToFailed>True</MapInconclusiveToFailed> <CaptureTraceOutput>false</CaptureTraceOutput> <DeleteDeploymentDirectoryAfterTestRunIsComplete>False </DeleteDeploymentDirectoryAfterTestRunIsComplete> <DeploymentEnabled>False</DeploymentEnabled> </MSTest> </RunSettings>
- Add this file via the Test menu by clicking TEST\Test Settings\Select Test Settings File and browse for your .runsettings file.
For further information, have a read through this article.
Trace Testing with SQL Server
You can use the SQL Server Profiler to monitor your data’s performance. For more information on the SQL Server Profiler, have a look at this resource. For an example on using SQL Server Profiler to replay trace files, have a read through this Microsoft article.
Trace Testing in Visual Studio
You can view a stack trace to see contextual information about any failure in a unit test. You also can navigate directly to the point of failure in the test. The stack trace is displayed on the Test Results Details page in Visual Studio. Stack traces are also written to a test results (*.trx) file for that test run. This means that if you open a test results file in Visual Studio, you can view the stack trace that was logged for that test run.
View a Stack Trace and Navigate to Point of Failure
More Testing Tools
Conclusion
Thanks for reading! I hope you have benefited from this article. Until next time, cheers!