Development Matters Blog

You have installed the Microsoft Dynamics CRM 5.0 CTP 3 version on Windows Server 2008 R2. Over time, you have made a lot of customizations – mostly based on Jscript. You decided to add some custom workflows and additional plug-ins for CRM and you decided to install Visual Studio 2010 with latest SP. Installation was finished successfully and you are able to use Visual Studio for development. However, adding web reference in the VS project indicates that the CRM server is not available. When you try to assess it via URL you are getting the configuration error like on the screen bellow:

To resolve the issue follow the next steps:

• Check the Application pull for CRM
  • Select Advanced Settings for CRMAppPool on the IIS server and be sure that it is using appropriate .NET framework version. It should be v4.0.30319.
• Check the CRM site
  • Select Microsoft Dynamics CRM site and the Handler Mappings on the right panel. Check all resources have a valid path (especially those which ends with 64bit). A path should end up with the folder which contains the appropriate dll or managed code defined in the feature. Make sure that appropriate framework version is used. For features which contain 4.0_64bit in name path should point out Framework v4.0.30316
• o Restart ISS and try to access the CRM Server.

“Not being able to reproduce it, not a bug” is a developer’s main philosophy. And generally it can be accepted as a fact. This is one challenge which continues to appear in different forms and testers need to spend a considerable amount of time analyzing environments, build versions, preconditions, and code without any guarantee that any verification process will provide precise information to what caused an issue.

So, are non reproducible bugs one of the most frustrating and toughest challenges for a QA?

One of the most interesting improvements in the Microsoft Visual Studio 2010 which should help both developers and testers is the option to collect IntelliTrace files during the test process. New Visual Studio 2010 allows testers to save rich test logs when running test cases and attach them with the bug. Developers can debug the code reproducing the steps recorded in those files, they can go back and forward in the call stack and analyze parameters and result values. The main advantage is that the developer’s environment can be completely different from the one where the file has been recorded. This is accomplished by deploying the IntelliTrace diagnostic data adapter (DDA) to the target system as part of the Visual Studio Test Agent or by deploying the IntelliTrace.exe command-line utility.

IntelliTrace has two main modes it can run under. In the default mode, IntelliTrace will just be collecting debugging data at the predefined IntelliTrace event points. While in the “methods and calls” mode, IntelliTrace will be collecting debugging data (including method parameters and return values) for all function inputs and outputs for all included modules. The “methods and calls” mode provides a lot of additional information about your application’s recorded execution path, but at a substantially higher cost in terms of time overhead and log file size.

However, there are several drawbacks related to this feature:

• The IntelliTrace DDA and/or IntelliTrace.exe cannot be used on a machine or a server in the production environment
• IntelliTrace files created using either methods can be opened and debugged only by using Visual Studio Ultimate.

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.

One of the main problems for any test engineer working with a test automation tool is how to resolve the situation when the tool doesn’t work properly. A distinction between an average and good test tool is the way of handling these situations. The minimum that one “good tool” must provide is a log with information of what happened in that test run in order to reduce engineering time necessary to fix that problem or find a workaround. However, this information is in the same time very sensitive, because it might contain an answer to a question if the tool has support for certain platforms.

CodedUITest in Visual Studio 2010 is well equipped with the Debug Trace, containing detailed information about time spent, action performed, control found and even expected time to complete a specific action. This log also contains technology used by Visual Studio to find control, so an average user can try to find out what the cause of the issue is. In a lot of situations, a set of such information will give a user an adequate reason for test failure.

W, 10220, 13, 2010/06/30, 08:28:33.358, 281524579375, QTAgent32.exe, PERF WARNING: FindAllDescendents: took 838 ms. Expected it to take maximum 500 ms.

W, 10220, 13, 2010/06/30, 08:28:35.085, 281529640405, QTAgent32.exe, Playback – {1} [SUCCESS] MouseButtonClick – “[UIA]ControlType=’Button’ && AutomationId=’btnCreateProject’”

W, 10220, 13, 2010/06/30, 08:28:35.663, 281531333898, QTAgent32.exe, Playback – {2} [SUCCESS] MouseButtonClick – “[UIA]ControlType=’Button’ && AutomationId=’NextButton’”

However, the user can enable more detail tracing in two ways

- The first one is by enabling trace for all Testing Tools in VS is to modify the following registry file:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\EnterpriseTools\QualityTools\Diagnostics]
“EnableTracing”=dword:00000001
“TraceLevel”=dword:00000003

EnableTracing key defines whether tracing is ON or OFF.

o 1 – ON
o 0 – OFF

- The other way is to set EqtTraceLevel or UITestTraceLevel switch in the appropriate exe.config file. The EqtTraceLevel will enable tracing for all Testing Tools modules of the executable. UITestTraceLevel will enable the tracing for only the UI Test modules of the executables.
For UI Test, the trace file is generated in %temp%\UITestLogs\*\LastRun\UITestLog.html where * could be empty for VS or could be exe name like CodedUITestBuilder for other cases. The LastRun here indicates that this is THE file for last run – the earlier ones would be stored as PreviousRunXX. The tool automatically cleans up the old trace file if it exceeds ‘n’ (today it is 25) previous runs.

This log is very useful for an experienced user as it contains full Microsoft Visual Studio log with API calls, the result of API calls and other algorithms used.

Obviously, it doesn’t mean that the user will be able to resolve all situations, but this log will increase productivity of automated software testers by giving them deep information about how the tool works, it will give them an idea how to resolve an issue or how to find workarounds. And if the log shows that the selected UI Technology is not supported, users can extend platform as this framework has been created with idea to overcome situations where this engine will not meet the needs and these means to test applications built on a different or new UI technology.

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.

The new Visual Studio 2010 RC brings significant changes in the domain of the coded UI tests. You can realize that if you try to build a test project in this new environment as you probably get more than 1000 errors. A few errors seem to happen a few hundred times each:

• Microsoft.VisualStudio.TestTools.UITesting.UITestControlProperties’ is inaccessible due to its protection level.
• The name ‘HtmlProperties’ does not exist in the current context.
• The name ‘UITestControlProperties’ does not exist in the current context.
• The name ‘WinProperties’ does not exist in the current context.

However, you can upgrade your project with an automatic upgrade script to move your automation:

1. Launch the Visual Studio Command Prompt from Start Menu > All Programs> Microsoft Visual Studio 2010> Visual Studio Tools
2. Run the script

UITestUpgrade.exe < folder to upgrade>

The upgrade tool will fix all of the changes listed below:

• All of the folders under the specified folder(s) is searched recursively and all projects under it upgraded.
• If a project is under source control, the upgrade tool will perform a check out and make changes.
• Tool will create a backup folder with all contents of the specified folder.

The Release Candidate (RC) version of Visual Studio 2010 has been released by Microsoft and is now available for download. From a tester’s point of view, Visual Studio 2010 Beta is a revolutionary step from Microsoft with a bunch of new stuff in Coded UI test for automation testers.

Visual Studio 2010 RC made some significant improvements of which I chose following:

Pause playback to wait for certain event

This capability was not available in VS 2010 Beta 2 and it was noticeably lacking. For example, it was impossible to wait for the form, message, progress bar to disappear etc.

This was accomplished with a modification of the UITestControl class. In the RC, you can use the appropriate UITestControl methods from the list.

1. WaitForControlReady() – This waits for the control to be ready to accept mouse/keyboard input.
2. WaitForControlEnabled() – This waits for the control to be enabled.
3. WaitForControlExist() – This waits for the control to exist on the UI.
4. WaitForControlNotExist() – This waits until the control ceases to exist on the UI.
5. WaitForControlPropertyEqual(string propertyName, object propertyValue) – This waits for the specified property of the control to have the given value.
6. WaitForControlPropertyNotEqual(string propertyName, object propertyValue) – This waits for the specified property of the control to not have the given value.
7. WaitForControlCondition(Predicate conditionEvaluator) – This waits until the specified predicate returns true.

(more…)

Visual Studio 2010 and .NET Framework 4 RC (Release Candidate) were made available to all MSDN subscribers on February 8.

The rest of the world will have a chance do get it on Wednesday, February 10th. This version also includes a go-live license.

For more information on the RC, visit Jason Zander’s Weblog.

Happy coding!

Microsoft has rescheduled the launch date for Visual Studio 2010 and .Net Framework. The original launch date was scheduled for March 22nd.

The new release date is April 12th.

Until then, learn more about Visual Studio 2010 Beta 1.

While creating UI Coded test Visual Studio 2010 Beta 2, I have experienced an interesting situation on identifying dynamically created controls.

An application contains a form with three WPF combo boxes created dynamically with a blank Name property. In this case, UI Spy (and I assume Visual Studio 2010 Coded UI Test Recorder) should identify control with empty Name and AutomationID property, but recorder should generate NextTo or Instance properties.

Unfortunately, recorder didn’t record the instance property, so the result was only one combo box control in the UIMap.Designer.cs file.

public WpfComboBox ItemComboBox

        {

            get

            {

                if ((this.mItemComboBox == null))

                {

                    this.mItemComboBox = new WpfComboBox(this);

                    #region Search Criteria

                    this.mItemComboBox.SearchConfigurations.Add(SearchConfiguration.NextSibling);

                    #endregion

                }

                return this.mItemComboBox;

            }

        }

The resolution is to create two new instances of the controls with different search criteria:

public WpfComboBox ItemComboBox2

        {

            get

            {

                if ((this.mItemComboBox2 == null))

                {

                    this.mItemComboBox2 = new WpfComboBox(this);

                    #region Search Criteria

                    this.mItemComboBox2.SearchProperties["Instance"] = “2″;

                    this.mItemComboBox2.SearchConfigurations.Add(SearchConfiguration.NextSibling);

                    #endregion

                }

                return this.mItemComboBox2;

            }

        }

However, a suggestion is to assign a name to these controls because in that case, they have a much better search condition and will be resilient to position changes.