This time I wanted to show the research we made with my colleague David Frassoni about recommendations and tips when handling exceptions and validations in C#.

When to Throw an Exception

We should not throw exceptions for every erroneous event. For example in an application in which we want to get a list of students, and there are no students matching with the user’s search, we should not throw a custom exception (e.g.: NoStudentsFoundException), because it’s not actually wrong. In this case it’s recommended to return a state value (e.g.: an empty students list or “null”).

When throwing an exception, don’t use “throw new Exception()”, it’s too generic. We should use the most accurate exception possible according to the operation we are handling.

When throwing an exception in a catch statement, we should append the Inner Exception to keep track of the initial cause.

There are situations where is not recommended to append the Inner Exceptions. For example, in a multi-layer application, if an exception occurs while performing a specific query to the database, if we re-throw the exception through the entire application until we reach the UI layer, we can expose sensitive information to the user. It’s important to be aware of this and know when to stop handling the Inner Exception through layers, and expose to the user a clear message of the exception, without sensitive information. We will talk about this later in this post.

Handling Multiple Exceptions Type

In case we need to handle each different exception in a different way, we should use one single try with several catch statements below it, one for each different type of exception that may occur in the code within the try. Also the catch statements should be placed in order, from the most specific to the most generic one, to handle the specific exception before it is passed to a more general catch block. The finally statement should be used to de-allocate resources, if applies.

Data Validation

To avoid unnecessary exception handlings, external data should be always checked before operating with it, even if it was a file that we’ve just written, or properties we’ve just received from a form. We should never trust anything coming from outside our application. Sometime, as we may use that information to hit a data source, they can contain unexpected code that can harm it, or even delete it.

Disposing Objects Properly

We should use the using statement in as many places as we can in our code, when we are dealing with Disposable objects. This way we prevent resource leaks even in the presence of an exception.

Validating vs Throwing Exceptions

There are some situations where it’s better to programmatically check for a condition in a block instead of catching an exception that eventually would be thrown. We can simply use an if statement to check if a condition matches a proper state, and then do something, instead of catching the exception that will be caused if not using the if statement. The fact that allows us to choose one or the other method is how often we expect this event to occur:

• If the event occurs in exceptional cases, use exception handling with try/catch/finally statements. This way is better than programmatically check the condition because less code is needed in the success case.
• If the event occurs often, use programmatic checks. This way is better than handling the exception because that will require more processing effort.

Atomicity

After an exception handling, we should check that we came back into a valid state, and no undesired effects occurred as a consequence of the exception. For example, if working with a transaction to a database, ensure that the atomicity principle is applied.

Custom Exceptions

We can create a custom exception when the exception types given by .NET Framework do not fit our needs. When creating custom Exceptions:

• Define new exception types only for programmatic scenarios.
• Inherit from the Exception class. It was originally thought that custom exceptions should derive from the ApplicationException class; however in practice this has not been found to add significant value.

Exception Messages Format & Logging

Messages thrown in exceptions should be grammatically correct, concise about the problem and end with a period.

We should always log the exceptions the application throws. When doing this, we should log Exception.ToString(), not only Exception.Message, because this way we can obtain the stack trace, the inner exception and the message.

Handling exceptions within different layers

In most common applications with an infrastructure layer, a business layer and a high-level layer, there are some recommendations to perform a good exceptions handling:

In the Infrastructure layer, lots of exceptions throws are performed, because it deals with the data sources, and it’s more prone to exceptions. At this level, there are practically no catching operations.

As regards the business layer, it serves more for validations and filtering of exceptions messages. Here is where we should resolve all the business requirements, validating programmatically our code blocks. We should catch exceptions coming from the infrastructure layer here for not exposing sensitive information in exceptions messages to the high-level layer.

Finally, in the high-level one, we will perform mainly catches to handle exceptions coming from the infrastructure or business layer. At this point, no exceptions should be thrown, because we only have to show the information to the user. If an error occurs, we should warn the user about it in a friendly message.

There are some frameworks and libraries you can use to deal with exceptions. Some of them are:

• Microsoft Enterprise Instrumentation Framework
• Apache log4net
• Microsoft Enterprise Library
• ELMAH (Error Logging Modules and Handlers)
• System Monitoring Components

Sources

Thanks to Hernan Meydac Jean and Jorge Rowies for their contribution on this post!

Recently I’ve been working with Web Performance and Load Tests in Visual Studio 2010, with the objective of measuring some metrics of a web site, like the average page time and the average first byte time. To do this, I had to record several web tests to serve as the input of the Load test, which will finally show the metrics we want to measure. In this case, the web tests are based on the System Test Cases developed for this web site, but they also could be based on the use cases in a case where the test cases are more granular.

In a first section in this post, we will see how to easily capture the web requests of a test case using Fiddler, and then export them as Visual Studio Web Tests, so we can manipulate their settings, such as Request Timeout, Credentials, etc., using Visual Studio.

In a second section, we will see how to create a Load Test from the scratch using Visual Studio and feed it with the web tests already recorded, how we can easily manipulate its properties, how to execute it focusing on counters such as Average Page Time and Average First Byte Time and how to interpret the results obtained.

Prerequisites

• Fiddler Web Debugger
• Visual Studio 2010 Ultimate
• A Test Rig (Controller and Agents) properly configured to run Load Tests

Section 1 – Web Performance Tests

Recording Web Performance Tests using Fiddler
Once Fiddler is opened and before recording any request, we will ensure that it’s capturing the Web traffic by checking the Capturing message at the bottom left corner of the window.

Now, we are ready to start recording all the web requests of a Test Case. Open a browser, and log in to your web site (with your credentials if necessary).

Once in it, follow the flow of the test case that you want to record. When finished, go back to Fiddler and you will see all the web requests recorded.

Click Capturing at the bottom left corner of the window to stop capturing the web traffic. You will notice that the label Capturing disappears.

Now that we have our requests recorded, we will proceed to export them as Visual Studio Web Tests to open them in Visual Studio and manipulate their properties. To do this, go to File | Export Sessions | All Sessions. A new window will open to select the Export Format.

In the dropdown list, select Visual Studio Web Test and click Next.

After that, you will be requested to select the folder where you want the web test to be saved and to provide a name for it.

Finally, you have your web test ready to be included in your Test Project in Visual Studio.

Manipulating Web Tests in Visual Studio

The next step will be to modify some properties of the web test already recorded with Fiddler, so it’s ready to be executed, using Visual Studio. In this case, we will focus on modifying the Timeout property of all the requests in the web tests to match a Performance Requirement of 4 seconds, and then we will add the necessary credentials for the requests to properly access the web site.

First, we will include the new web test to our Test Project in Visual Studio. To do this, right click your test project in Visual Studio and select Add | Existing Item. Browse to your .webtest file and click Add.

The web test is added to the project.

Double-click the Web Test that you have already added. You will see the list of recorded requests performed in Fiddler.

Editing the Timeout property

In the web test tree, right click the first request and select Properties. All the properties for that request will be displayed, and among them we will see the Timeout, which is the one we will modify to match the Performance Requirements.

In the Timeout option, insert the required amount of seconds (in this case, 4).

Now, do the same for all the other requests.

Note: To speed up this process of modifying the Timeout for each request, you can press CTRL + H to open the “Find and Replace” dialog, and replace each Timeout=”60” for Timeout=”4” in the entire solution.

Adding Credentials

The last thing to do will be to add the credentials for the web test. To do this, click Set Credentials in the web test Menu.

Now, insert the Name and Password used when recording the test in Fiddler and click OK. Save the web test.

Finally, the web test is ready to be executed.

Updating the Site URL

In case you have to update all your web tests because the URL of the site under test has changed, you can simply press CTRL + H, and replace all the old URLs with the new one.

Note: some web tests can fail if the data used to execute the test wasn’t previously uploaded to the site in the test initialization.

Executing a Web Test

In order to execute the web test, click Run Test in the web test Menu.

Verify that the web test executed successfully. You can check some information about the test execution (Request Time is one of the important metrics).

Section 2 – Load Tests

Creating a New Load Test

In order to create a new Load Test, right-click your test project and select Add | New Test.

In the Add New Test window, select Load Test, provide a name for it and then click OK.

After that, a wizard will be displayed, where you will configure your load test. Click Next in the Welcome section.

The next step will be to configure the scenario where the load test will be executed. You will be requested to insert a name for the scenario and the Think time profile that you want to use. Provide a name, leave the think time profile by default to use the recorded think times in the requests and click Next.

Note: Think time is the time spent by a user perusing a Web page, including viewing the page and determining the next action. Think time does not include the time that is required for a page to load.

In the Load Pattern step, we will have to specify if we want a constant load of users during all the simulation, or if we want to increase the amount of users in steps. The difference between both of them is the duration of the simulation.

By choosing the first one, we should specify a warm up time for the load test, until the user count reaches the inserted value. This will cause the whole simulation to last less time than the one with a step load, because the amount of users will increase lineally until the maximum specified count, with no major complications for the processor of the machine that is executing the test.

By choosing the second one, we will have to specify the start user count, the step duration, the step user count and the maximum user count values. In this case, the duration of the simulation will have to be bigger than the other one, because if we choose a big amount of users per step, the processor of the machine that is executing the tests can start to fail, and the simulation results could not be entirely correct. We also should specify a short warm-up time at the beginning until the start user count is reached.

Note: When you specify a warm-up time, you avoid over stressing your site by having hundreds of new user sessions hitting the site at the same time. Also, the results obtained during this time will not be taken into account for the final results.

After choosing the load pattern, click Next.

The next thing to do will be to choose the Test Mix Model that we want to use during the execution of the load test. This model specifies the probability of a virtual user running a given test in a load test scenario. This lets you simulate load more realistically.

Choose the Based on the total number of tests mix model, so we can select the distribution for each web test that we want to run in the load test in the next step, and click Next.

In the Test Mix section we will be able to add the web tests that the load test will use in the simulation to hit the web site. Also we will choose the distribution of the web tests, to indicate which ones we want to occur more times than others.

To add the web tests, click Add.

In the Add Tests window, choose the web tests included in the current project that you want to be executed during the simulation and press >. Click OK to close the Add Tests window.

Back in the Test Mix section, choose the distribution for each web test and click Next.

The next step will be to choose the Network Mix, which is a combination of two factors: the selection of networks that are contained within the scenario, and the distribution of those networks within the scenario.

Add the networks that you would like the load test to mix, select their distribution and click Next. By default, we will only use LAN.

Another thing to specify is the Browser mix. This let us send the requests through different types and versions of browsers. We can add all the browsers that we want the load test to use and their distribution. By default, we will only use Internet Explorer 9.0. After selecting it, click Next.

Note: you will notice that Internet Explorer 9.0 is not loaded by default in Visual Studio. In order to add other browsers to test, take a look at this article.

In the Counter Sets section, we will add the controller computer and agents that will execute all the web tests in the load test. These ones will be available according to the configuration of the Test Rig that is required to execute Load Tests. In this case, we choose only one agent (which is the only one configured in the machine). Click Next.

The final step in the creation of a Load Test is to specify the Run Settings. You will be able to choose between Load test duration, where a warm-up time and a run duration will be required, and Test iterations, where you can select the number of times to run the test. By default, we will choose Load test duration. Provide a long warm-up time if you have chosen a constant load of users in the Load Pattern section of the wizard, or a short warm-up time if you have chosen a Step load of users. After providing also the duration time, click Finish.

Our Load Test is finished and added to our test project. Now we are ready to execute it.

The recommendation for a proper simulation is to choose a constant load of users (the maximum available in Visual Studio is 250 without license, and packages of 1000 users per license), a long warm-up time until the maximum specified amount of users is reached, and almost 15 minutes of simulation with the system stressed with the maximum load.

Manipulating Load Tests in Visual Studio

Once we have our load test created, we can take a look at its properties, and modify them as we wish. This is useful to, for example, edit the total duration of the simulation, edit the warm-up time, add new web tests to the Test Mix, select Initialize tests and Terminate Tests, etc.

Updating the Scenario

In the load test tree, right-click the scenario and select Properties. The Properties pane should display.

Select Test Mix Type and click the Ellipsis next to the text mix type. The Edit Test Mix window should appear.

Here we can change the text mix model by selecting one of them in the dropdown list, add more web tests to our set by clicking Add, and also change their distribution.

Note: an alternative way to add new web tests to the test mix is by right-clicking Test Mix under the scenario in the load test tree, and selecting Add Tests. Analogously, the same can be done to add more browsers to the Browser Mix, or networks to the Network Mix.

Apart from that, we can set an Initialize test and a Terminate test for all the web tests in the list. This means that before every web test that a user will execute in the simulation, the Initialize test will execute, and after the execution of all the web tests, the Terminate test will do so.

At the beginning we thought that this could be a good way to initialize the environment where we were working on in order to isolate the tests execution, but then we found a disadvantage that forced us to discard it:

• Only one web test can be selected to run as Initialize test

What we really needed was to execute several web tests to initialize the environment before the execution of each web test in the load test.

Finally, another thing to consider is that we can change the Load Pattern from the load test tree. Just right-click the load pattern and select Properties. Here you can select the pattern you want from the dropdown list, and also manage its properties.

Updating the Run Settings

In the Run Settings section, you can basically edit the duration of the simulation and the warm-up time, among other things. Right-click the Run Settings in the load test tree and select Properties. You will be able to edit them in that pane.

Executing a Load Test

Now it’s time to execute our load test. To do so, click Run Test in the load test Menu.

The test will start to run, showing different graphs with the progress of the simulation. Those graphs show the current selected counters (you can find them in the Counters pane at the left side of the screen after expanding the nodes), such as User Load, Pages/Sec, Avg. Page Time, etc.

An important thing to mention is that all the counters offered by Visual Studio are recorded during the simulation. We choose only the ones we need to show in the graphs, tables, etc., but we can also add new ones to the report after the simulation is finished.

Interpreting Load Test results

When the load test finishes, all the results are stored in the database, and Visual Studio generates a general report. In this section, we will review most of the important things on it.

Summary View

Once the results are stored in the database, a Summary of the simulation is displayed.

An important section in this summary is the Overall Results, where some of the important counters are displayed. You can check the other ones in the Tables view.

Note: you can change the layout of the reports in the Load test menu. The different views are Summary, Graphs and Tables.

Graphs View

In this view, you can select the graphs that you want to display. The tables below them will update automatically.

The Key Indicators graph shows the behavior of the selected counters for this simulation, and it shows metrics such as minimums, maximums and average of each counter. If you compare this graph with the one shown in the Executing a Load Test section of this post, you will notice that the results obtained during the warm-up time (5 minutes) were removed.

Note: the Range column in the Key Indicators table shows the axis range of that counter in the graph.

Counters

• Pages/Sec: it measures the hard page faults per second. A hard page fault occurs when a memory page is not in the immediate memory and needs to be fetched from the disk.
• Avg. Page Time: is a measure of the average time to download the page and all of its dependent requests, such as images, css, js, etc.
• Avg. Response Time: is a measure of the average time that took to give a response after a request.
• Avg. First Byte Time: is a measure of the average time that took to start receiving data back from the server.

Note: the Average First Byte Time is not displayed by default. To display this counter in the table and the graph (as shown in Figure 41), you have to expand the Overall node in the Counters section at the left side of the screen, then expand the Request node, and then double-click Avg. First Byte Time.

The Controller and Agents graph shows the performance of the processor and the memory of the machine that is executing the load test. This is an important thing to consider, because if the processor starts to fail more often, the metrics showed in the Key Indicators graph are not entirely correct. So, this indicates the time where the simulation performed correctly, and the time where the results are not entirely reliable (if the processor failed during a considerable time). When giving a report, we should only consider the first case.

Tables View

Finally, you can check the errors and the statistics of how many times each web test failed or passed within the execution of the load test in the Tables view. By following the links of the failures, you will get more information about the errors.

Sources

• How to: Visual Studio web performance tests – not using Internet Explorer
• How to: Create a New Load Test Using the New Load Test Wizard
• Configuring Test Controllers and Test Agents for Load Testing
• How to: Create Run Settings in the New Load Test Wizard
• Considerations for Load Tests
• How to: Edit the Text Mix Model Using the Load Test Editor (to add Initialize and Terminate tests)

I hope you can find all of this useful!

Thanks!

I would like to show how to run MSTest in a single MSBuild script. Basically what I did is to execute MSTest.exe and pass the test assemblies and the test settings via command line. You should always include the test settings file because it tells if the Code Coverage is enabled, and in which assemblies.

First of all, in our build script, we have to specify the path to MSTest.exe. We will then create a new target in our build script where we will execute the tests.

NOTE: Ensure to put this target after compilation so the test assemblies are generated.

To pass the test assemblies and the test settings to MSTest.exe, we will use the /testcontainer and /testsettings command line options respectively. If you want to include several test assemblies, you have to put as many /testcontainer as assemblies you have. Here is an example:

<Target Name=”RunTests” DependsOnTargets=”Compilation”>

<Exec Command=”&quot;$(MSTestPath)\MSTest.exe&quot; /testsettings:{path-to-test-settings-file} /testcontainer:{path-to-test-assembly1} /testcontainer:{path-to-test-assembly2} /testcontainer:{path-to-test-assembly3}”/>

</Target>

This will run all the tests in the assemblies that you passed and will generate a TestResults folder with all the information to measure Code Coverage (if you enabled it in the test settings file).

I hope you find this information useful. Please provide any feedback you consider necessary.

Thanks!

Recently I’ve been working with TeamCity 7 and getting involved in the continuous integration practice, so I would like to show my experience in this post.

For my project, “build” means the following things: compiling, checking Source Analysis, checking Code Analysis, running Unit Tests and measuring Code Coverage. Taking this into account, I will show you how to configure TeamCity 7 to perform all these tasks automatically in a VS2010 .NET solution, with .NET Framework 4 and a Git repository.

First of all I had to create a new project. I did this in the Administration > Projects section, clicking Create new project and providing a name for it. After that, I had to create a new configuration for my project. This configuration has various “steps” to configure.

Configuring General Settings

In this section I only provided a name for the new configuration. I left all the other values by default.

Configuring Version Control Settings

In this section I had to specify the URL of the Git repository that I’ve been using to commit the source files of my application. To do this, I clicked Create and attach new VCS root and then, when the New VCS Root windows is displayed, I specified the URL of my repository and set the authentication method to Private Key, indicating the Private Key Path too.

TeamCity will be monitoring my repository according to the triggers that I specify in the build execution. On each build, TeamCity will search for changes in my repository and will execute the defined Build Steps. I will show all of this configuration in in the next sections.

Configuring Build Steps

This is one of the most important parts of the configuration process, because Build Steps are the actions that will be executed when a new build runs. In my configuration, I had to create 3 Build Steps as shown in the following picture:

Step 1 – Source Analysis, Compilation and Code Analysis

This step will use a MSBuild runner with a ciserver.proj build file that resides inside the repository of the project. This build file has all the routines to check Source Analysis, Code Analysis and perform the compilation.

Ciserver.proj file

IMPORTANT: In order to successfully run this build file, you need to have Stylecop and MSBuild Extension Pack installed in the Server machine.

I defined all the paths to the working directory, FxCop and the Extension Pack at the beginning (they should be environment variables provided by TeamCity), so they can be passed to the tasks that are executed after that. In the ItemGroup tag I specified all the source code files in the repository, the assemblies to take into account, the rules to include, the soulution files and the ones that I want StyleCop to include in the checking.

• RunSourceAnalysis task: It depends on the StyleCop.dll assembly of the MSBuild extension pack. This task will take the files defined in the ItemGroup section and the Settings.Stylecop specified and will perform the check generating a log file with all the information of the execution.
• Compile task: It will perform the compilation of the solution. Notice that it depends on the RunCodeAnalysis task.
• RunCodeAnalysis task: It will check Code Analysis in the assemblies defined in the ItemGroup section, and generate the results in a txt file. It also depends on the Compile task.

All the result files generated by StyleCop and FxCop will then be used to show the Code Metrics reports in the TeamCity UI. I will show how to do this at the end of the post.

Step 2 – Run tests

This step will use MSTest runner with the Local.testsettings and test-metadata (.vsmdi) files generated by Visual Studio. In the test-metadata file I included the list of tests that I want the Build Process to execute.

All the other fields are left by default.

Step 3 – Measure Code Coverage

For this step, I decided to execute a Build file called teamCityCodeCoverage.proj with a MSBuild runner and measure the coverage manually instead of using one of the tools that TeamCity provides (NCover, PartCover, dotCover, etc).

The only things that I had to provide in TeamCity were the path to the Build file, the .NET Framework used and the platform (x86 in this case). I left all the other fields by default.

teamCityCodeCoverage.proj

When the Tests were run in the previous Build Step, a sort of TestResults folder is created in a temp folder inside TeamCity path. It is the ArtifactDirectory path that is displayed in the previous image. Inside of it we have 2 important assets: The Out folder with all the assemblies of the test results, and the data.coverage file with the coverage information inside a In folder. All these stuff will be passed to the CoverageConvert.exe tool (this is an internal tool developed by the engineering excellence team), which will process them and produce a CodeCoverage.xml file with all the results of the measurement. But this is a lot of information to show in a report, so I used some assemblies to transform this xml into a html file with the summary of the Coverage.

Folder with build files and Coverage tools

NOTE: The disadvantage of measuring Code Coverage like this is that these assemblies have no maintenance and are a blackbox, although they were developed here in Southworks.

Configuring Build Failure Conditions

In this section you can specify when the Build should fail. Notice that you can add custom Build Conditions apart from the ones provided by TeamCity. In my case, I added two build failure conditions when there are Source Analysis or Code Analysis violations. Basically in the ciserver.proj file I show a status message when the check of Code Analysis and Source Analysis finishes. This will be printed in the Build log of TeamCity, so I added my custom failure conditions to fail the build if the status messages of Source Analysis and Code Analysis in the Build log of TeamCity are failure.

Configuring Build Triggers

In this section you can specify the triggering of the Build Process. In this case, I decided that the build process should start after a new commit is detected in the Git repository, so I chose a VCS trigger.

How to Show the Code Metrics Reports in the TeamCity UI

TeamCity 7 provides custom report tags. These ones are useful to show reports generated by other tools, like in this case, Source Analysis, Code Analysis and Code Coverage. To make this happen, we have to store these 3 reports as artifacts from the build.

To do this, we specify the path to these files in the General Settings section of the Project Configuration Wizard.

After that, we will create a new report tag for each report, and retrieve the report from the artifacts generated by the last successful build. To do this, click Administration at the top right corner, click your project’s name and the click the Report tabs tab. There you can create all the tabs that you want, specifying the build which the artifacts will be taken from, and the file names. These artifacts will be taken from the data-directory path of TeamCity, in this case, under Users\User\.BuildServer7\system\artifacts\{projectname}\….\{file-name}.

Then, you can see the new tabs in the Project’s Home page, displaying the required reports.

I know that the Code Analysis report is not very consumable, but I will show another alternatives for reporting it in another post.

I hope that you find all this information useful!

Thanks!