Monday, May 19, 2014
Monday, May 19, 2014 5:02:00 AM (Eastern Standard Time, UTC-05:00)
 Monday, September 23, 2013
Monday, September 23, 2013 7:24:59 PM (Eastern Standard Time, UTC-05:00)
 Monday, March 04, 2013
Monday, March 04, 2013 12:53:08 AM (Eastern Standard Time, UTC-05:00)
 Friday, November 02, 2012
 Thursday, November 01, 2012

This screencast demonstrates how to change a Visual Studio 2012 Coded UI Test after you have recorded it.

Thursday, November 01, 2012 9:28:00 AM (Eastern Standard Time, UTC-05:00)
 Wednesday, October 31, 2012

This screencast shows how to add assertions to a Visual Studio 2012 Coded UI Test while recording your mouse and keyboard actions.

Wednesday, October 31, 2012 9:26:00 AM (Eastern Standard Time, UTC-05:00)
 Tuesday, October 30, 2012

This screencast covers the fundamentals of Microsoft Coded UI Tests, a feature of Visual Studio 2012, Premium and Ultimate Editions. You will learn how to record mouse and keyboard actions to record a simple "smoke test".

Tuesday, October 30, 2012 9:25:00 AM (Eastern Standard Time, UTC-05:00)
 Sunday, October 28, 2012
 Saturday, October 27, 2012

This screencast demonstrates how to change a Visual Studio 2010 Coded UI Test after you have recorded it.

Saturday, October 27, 2012 9:22:00 AM (Eastern Standard Time, UTC-05:00)
 Friday, October 26, 2012

This screencast shows how to add assertions to a Coded UI Test while recording your mouse and keyboard actions.

Friday, October 26, 2012 9:19:00 AM (Eastern Standard Time, UTC-05:00)
 Tuesday, July 24, 2012

Functional testing, system testing, and acceptance testing of software often involves manual actions by a user. To verify that an application works as designed, a user launches the application, navigates to a specific module, enters some data, and verifies the expected output.

Such testing tends to be expensive in terms of time, labor, and money. In addition, like all activities requiring human intervention, testing in this manner can often be error-prone and inconsistently executed.
Microsoft Visual Studio 2010 Premium and Ultimate contains the Code UI Testing tool that provides a way to automate these tests, so that regression testing can be performed more quickly, efficiently, and consistently.

A Coded UI Test gives developers and testers the ability to create tests that simulate user interactions with an application.
Coded UI Tests are stored in a Test Project. To create a new Test Project in Visual Studio,

  1. Select File | New | Project… The New Project dialog displays. 
  2. In the Installed Templates panel, expand the Visual C# or Visual Basic node and select the Test category.
  3. In the Project Type panel in the middle of the New Project dialog, select Test Project.
  4. Enter a name and location of the Test Project.
  5. Click the OK button. Visual Studio creates a new Test Project. You can view it in the Solution Explorer.

In our example, the project is named TestProject1. Link: Download TestProject1.

By default, a new Test Project contains a Unit Test class named UnitTest.cs. We won’t need this class, so it is safe to delete it.

Add a Coded UI Test to the project. (Project | Add Coded UI Test…) and provide a meaningful name for the map class.

The Generate Code for Coded UI Tests dialog displays. Select the Record actions, edit UI map or add assertions radio button. Click the OK button.

The Coded UI Test Builder toolbar displays in the bottom right of your screen.

Click the record button () to begin recording your actions. From this point, you can launch an application, navigate to a web site, click buttons, or enter data into forms – pretty much anything you do with your mouse and keyboard will be captured and turned into code by the recorder.

You can stop the recording either by clicking either the Pause button () or the Generate Code button ().
When the recording is paused, you can add an assertion by holding down the left mouse button over the Add Assertion button () and dragging the cursor to a control that contains a property against which you will create an assertion. A blue outline appears around any control as the cursor moves over it. Release the mouse while over the control to create an assertion about that control. An assertion declares an expected property value of the control. Comparing the actual property value against the expected value.

Clicking the Generate Code button generates C# code that reproduces the mouse and keyboard actions that you performed while the recorder was running.

The Generate Code button creates or updates three files in your project. The You can generate code button and create assertions as often as you  like. When you close the Coded UI Test Builder, Visual Studio generates three files share a similar name but different extensions: *.uitest, *.cs, and *.Designer.cs.  In our TestProject1 demo, the files are named files UIMap.uitest, UIMap.cs, and UIMap.Designer.cs. Because these files are related, UIMap.cs, and UIMap.Designer.cs appear beneath UIMap.uitest within the project hierarchy.
UIMap.uitest contains an XML file with information about the recorded steps.  If you don’t have the graphical interface to edit this file, you may want to download the Visual Studio 2010 Feature Pack 2 (http://msdn.microsoft.com/en-US/vstudio/ff655021.aspx ). This XML file is used to generate C# code stored in the UIMap.Deigner.cs  file.
Using the Coded UI Coded UI Test Editor, you can view each recorded step, change properties of a step; and split a method into multiple methods.

UIMap.Deigner.cs is overwritten every time any new recordings are created, so you should not edit this file.  Instead, move the method you wish to modify into the UIMap.cs file. This file is not overwritten, so your code can store anything you want here. UIMap.cs and UIMap.designer.cs are partial classes of the same class, so it doesn’t matter to the compiler in which file a method, property, or field is located.

Tuesday, July 24, 2012 9:37:00 AM (Eastern Standard Time, UTC-05:00)
 Wednesday, June 27, 2012

If you are new to performance and load testing, you need two things: knowledge of testing practices and knowledge of testing tools. .NET Performance Testing and Optimization: The Complete Guide by Paul Glavich and Chris Farrell provides both of these.

.NET Performance Testing and Optimization provides a solid overview of good testing practices, as well as practical information on how to use various commercial testing tools that are currently available.

The first three chapters cover principles of testing, such as which metrics you can measure, what information each metric provides, and when to care about each metric.

Glavich and Farrell describe the different types of tests and the goals of each. Performance Testing, for example, measures the speed at which an application responds to user input and events. Load Testing measures the number of concurrent users an application can reasonably support. Although they are often confused, the goals are different and the important metrics for each are different.

The rest of the book describes in detail various types of tests you can perform. Glavich and Farrell even provide step-by-step instructions to perform these tests with popular commercial products.

For those new to performance testing, for those needing a refresher on performance testing, or for those who want to know how to use commercial products to perform performance testing, .NET Performance Testing and Optimization  is a good source of information.

Wednesday, June 27, 2012 9:47:00 AM (Eastern Standard Time, UTC-05:00)
 Thursday, May 24, 2012

Here is Phil Japikse’s presentation on Testing Code From The Pit of Despair at the March 2012 Great Lakes Area .NET User Group (GANG).

Thursday, May 24, 2012 11:06:00 AM (Eastern Standard Time, UTC-05:00)
 Monday, April 25, 2011
Monday, April 25, 2011 9:45:00 AM (Eastern Standard Time, UTC-05:00)
 Monday, April 18, 2011
Monday, April 18, 2011 8:45:00 AM (Eastern Standard Time, UTC-05:00)
 Wednesday, September 22, 2010

This is a 2-part recording of Jim Holmes's presentation An Introduction To Unit Testing, delivered at the September 15 meeting of the Great Lakes Area .Net User Group.

Part 1
Part 2
Wednesday, September 22, 2010 6:21:39 AM (Eastern Standard Time, UTC-05:00)
 Monday, July 19, 2010
Monday, July 19, 2010 7:46:06 AM (Eastern Standard Time, UTC-05:00)
 Monday, March 22, 2010

Episode 78

In this interview, Jim Holmes discusses the importance of unit testing in writing high-quality, maintainable code.

Monday, March 22, 2010 11:25:14 PM (Eastern Standard Time, UTC-05:00)
 Tuesday, February 09, 2010

Unit testing the critical methods of your application is important.

Generally, I focus on testing public methods because this is the interface that others use to interact with my library. Testing only public methods also safeguards me from modifying unit tests every time I refactor or optimize the encapsulated code of my libraries.

Unfortunately, sometimes critical methods are marked Private. Because I always create my unit tests in a separate project, this presents a problem: Private methods are only accessible to other methods in the same class; You cannot call a Private method from an external assembly.

You have several options when testing Private methods from a separate project.

  • Change the method's accessor to Public
  • Create a public 'accessor' to the method
  • Use reflection to access the method
  • Test a public method that calls this method.
  • Change the method's accessor to Internal and make Internal methods visible to your test project.

Each of these approaches has its shortcomings

Change the method's accessor to Public

This is probably too extreme as it breaks any abstraction you were trying to create. Too many public methods can clutter an API, making it overly complex.

Create a public 'accessor' to the method

This involves creating a public class and method decorated with the [Shadowing] attribute. It definitely adds a level of complexity to your class. When you ask MSTest to create a new Unit Test of a private method, you will be prompted to create an accessor.

Test a public method that calls this method

This is a popular choice. The idea is that public methods call private methods, so testing your public methods will call and test your private methods. To get good code coverage, you will need to know which methods are called (an approach known as "White Box testing".) Some people don't like to call this a unit test because multiple methods are called.

Use reflection to access the method

This is the most complicated of the methods listed here; But, if you don't have the source code and you feel you must test a private method, this is your only option.

Change the method's accessor to Internal and make Internal methods visible to your test project.

This method is a good compromise. By default, Internal methods are available only to other methods in the same assembly. However, you can an external project explicit permission to access Internal methods by adding the following line to AssemblyInfo.cs class of the file containing the method you want to test.

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("TestProject")]

where TestProject is the name of the project containing your unit tests.

When I have access to the source code, marking Internal methods visible is my preferred method of testing private methods. When I don't have access to source code, I tend only to test public methods.

Tuesday, February 09, 2010 10:54:29 AM (Eastern Standard Time, UTC-05:00)