Development Matters Blog

Microsoft continues to provide new features which should help in defect prevention during the software development process. With the new Visual Studio 2010, you can check which builds have bug fixes, new features, new requirements or user stories added. Built-in test reports now cover test case progress, test plans and test results.

But the really cool new feature in the VSTS 2010 is that you can also view recommendations about which tests might have to be rerun, based on the effect of code changes that have been made to your application if you are using Test Impact Analysis when you run your tests. This is an additional feature for the code review implemented for the first time in Visual Studio 2008.

The whole process requires collecting test impact data per test. Test Impact Data is actual information about the methods called during the test execution. What is really important is that Visual Studio will collect Test Impact Data for both automated and manual tests, during the test execution using Test Runner. Therefore, the user doesn’t have to spend time exploring the application code. The links between methods in the application and the test cases are stored to determine which test cases should be recommended to run again based on the changes to the methods.  This actually means that this feature will help in development from unit tests to manual tests and in both cases, the code analysis tool in the Visual Studio 2010 will shift user’s focus to the testing of the updated code.

If you have implemented Continuous Integration rather than running a build with a huge portion of tests you probably have a problem as it takes way too long to run frequently. If that’s the case, many administrators choose to exclude all – or a large number of tests – from the Continuous Integration, breaking a concept of the end-to-end builds process. The only remaining impact is Build Verification. By applying this mechanism in the TFS, the team should get a repeatable and reliable method to create a regularly available public build.

On the other hand, the developer is free to choose between a subset of tests (those that need to be run based on the code changes made) or running the entire suite of tests. This feature will point to both testers and developers what needs to be tested and which tests need to be run, especially since the test team often struggles with the details of what has been changed. Test Impact Analysis has a powerful mechanism to identify all changed points in order to help testers identify which tests need to be run in order to validate the new build.

Although, an investment in this feature increases maintenance time and requires a decent level of discipline within the development team, cost of the Test Impact Analysis implemented like this is significantly lower than benefits that team will gain.

A big innovation in Visual Studio 10 is the opportunity to wait for a UITestControl object to be opened or enabled before the rest of the test continues with executing. It can be very important if we test a project on a few different environments. In the previous versions, we used loops for checking the availability of the object, or we just made the process sleep for a while. Now, we can do the same with the following methods:

UITestControl::WaitForControlExist Method

public: bool WaitForControlExist()

Return Value is Type: System::Boolean. It is true if this control exists before the time-out, otherwise, it is false.

UITestControl::WaitForControlExist Method (Int32)

public: bool WaitForControlExist(int millisecondsTimeout)

Parameter is millisecondsTimeout, Type: System::Int32 and represents the number of milliseconds before time-out.

Return Value is Type: System::Boolean. It is true if this control exists before the time-out, otherwise, it is false.

UITestControl::WaitForControlEnabled Method

public bool WaitForControlEnabled()

Return value is Type: System.Boolean. It is true if this control is enabled before the time-out, otherwise, it is false.

public bool WaitForControlEnabled(int millisecondsTimeout)

Parameter is millisecondsTimeout, Type: System::Int32 and represents the number of milliseconds before time-out.

Return value is Type: System.Int32. It is true if this control is enabled before the time-out, otherwise, it is false.