Level 3 Testing Overview
Level 3 Quality means that the technical design of the generated application fits the migration team's architecture and development standards on the target platform.
Technical tests are critical to a VB6\ASP\COM to .NET migration effort because the two platforms are radically different. The proverbial "direct conversion" is not viable -- there are countless things that must or shouldchange. For example, certain VB6 statements and features of the VB6 runtime behavior that were implicitly or easily available are just not there anymore. If your legacy code does not use these statements or features, your migration will be easier, but if it does, you will have to decide if and they will be implemented important as part of the upgrade process.
Some of technical matters can be identified during the assessment phase of your project using various assessment tools as described in the Preparation section. Going beyond that, and actually solving those matters requires that you see how your target code measure up to your unique .NET development standards.
The .NET coding standards used in a migration should be the same ones you would use for writing new .NET code, and they lay out guidelines, policies, and patterns for how your code must be written in order to be maintainable, fast, secure etc. There are many generic standards for .NET programming available but typically you will have to well beyond that in order to define what is acceptable for your migrated applications. For example specifics about which .NET classes to use and how to use them in various scenarios.
Once you have defined your .NET coding standards you can examine the translations and identify specific things that must or should change. The main way to do this for migrated code is by code reviews. Code reviews can be automated using the code analysis capability built into Visual Studio, or using a external tool such as FxCop; it can also be done by looking at the code by eye or with a simple search tool.
Technical defects can typically be removed by modifying the configuration of the translator and re-running the translations. They can then be verified as being resolved, or not, using the Snapshot comparison features built into gmStudio.
.NET Build Test with Code Analysis
Most of the time you will be able to cover allot of ground with manual code reviews. However, the GMM is predicated on automation so an automated code review process is described here.
The .NET Build Test with Code Review verifies that the translations can be processed by MSBuild and also reports coding standards violations.
In order to activate code reviews with MSBuild you need to add a block of XML to your .NET project file. This can be done using a target edit like the one shown below
<gmBasic>
...
<Compile Project="%SrcPath%" />
<Analyse />
<Output Status="New" Filename="%BndPath%" />
<Author>
<Fix>
<!-- the following target edit turns on code analysis -->
<Replace name="U: Add Code Analysis to MSBuild step" lang="csproj">
<OldBlock><![CDATA[
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
]]></OldBlock>
<NewBlock><![CDATA[
<ErrorReport>prompt</ErrorReport>
<RunCodeAnalysis>true</RunCodeAnalysis>
</PropertyGroup>
]]></NewBlock>
</Replace>
</Fix>
</Author>
...
</gmBasic>
Once RunCodeAnalysis is on, the .NET Build Logs will include code analysis information. The Text Plan for the Standard .NET Build Test can also be used for the .NET Build Text with Code Analysis.
An alternative approach is to use an external code review tool such as FxCop. Running FxCop can be integrated into the project file or run as a post-build step using a User Batch Command Script.
Code analysis rules can be modified and even extended to check your own standards. Read the documentation of your Code Analysis tool for details.