We ported VB6 code to C # in .net

Question

This code has been ported using a third-party tool. what the tool could never do, it was done by the .net developers, so that all compilation problems were fixed. My question is that for these types of migration we are not trying to run unit tests for these functions.

Secondly, can anyone suggest whether to use any tool in VSTS 10 to create a UML model of this code in order to minimize the risks of problems that a client can find. How cumbersome it is.

Are there any other suggestions on how high-quality portable code can be delivered in light of the fact that the functionality of the original VB6 application is unknown to us.

Answer 1

for such migration operations, are we going to run unit tests for functions.

I would not trust the recently translated code (mechanical or otherwise) in general. He absolutely needs to be tested.

the functionality of the original VB6 application is unknown to us.

This will make regression testing quite ... difficult. If you do not know how this should behave, how do you know when you are done?

Of course, you could decide not to translate the unit test code, then you won’t know how the new code works - not sure if unknown = unknown counts as pass, however.

Answer 2

In my experience, the vast majority of applications provide a lot of "unknown" functionality. In the end, we write software to help us manage information in a way that immeasurably surpasses our capabilities, like just morality. Over time, the size and complexity of our software grows, grows, and grows until it contains a huge amount of "unknown" functionality. Unknown functionality was probably known and verified as "correct" at a time, and it was written in detail by the source code. However, over time, no one remembers / does not know what all the functionality is or even why it is "right." The full functionality is only “remembered / known” by the source code, the commands “check that they change”, and the rest are considered correct if there is no problem. This is especially true for systems that have been expanded and modified by many people for many years. Of course, this creates a risk, and we can do better, since TDD and tools for automating module testing help, but for many older systems, a lack of system understanding and incomplete testing is a fact of life. The technical idealist in me does not like this, but the business realist in me accepts it.

All that is said is a serious problem for migration groups. Theoretically, these commands "change everything." In the VB6-to-.NET migration, “Verifying that we have changed” means testing everything. Uch. Also, the functional requirements for migration are often "simply forced to do what it is doing now, but on a new platform." It is not very useful when people do not know / do not remember everything that the system does, not to mention how to verify that it does it correctly. I work with several clients who have huge VB6 applications containing 100 thousand LOCs organized in hundreds or forms and classes and several thousand methods, properties and event handlers. I am sure that these applications contain 10 thousand thousand points. I like to ask migration groups how long it will take them to find a mistake if I go into VB6 and “break” one small thing somewhere. I rarely get an answer ...

This is why I advocate the use of instrumental rewriting . One of the most important materials for this process is source code tested in production. We assume that this code is "correct", since you or your clients manage it on this. The source code is an extremely detailed, formal and complete answer to the question: what does the system do? In our approach, the migration team iteratively tunes, calibrates, and verifies the automatic, systematic translation and reorganization of the VB6 source to the full .NET source. We translate, test, tune and repeat; each time improving the quality of translation in terms of functional correctness and compliance with .NET coding standards. Testing and refining what the tool does is central to the methodology.

To check the quality of the code, we use code reviews and side by side. Code checking is done by checking .NET code with eyes and other tools such as .NET compiler, FXCop, NDepends, etc. We also compare a lot of successive generations of translated codes using a product such as BeyondCompare to verify that each change in the translation setting has the desired effect and undesirable side effect. Gradual testing is what it looks like: the general idea is to run legacy and .NET applications in parallel test environments and make sure their results and behavior match. There are at least a few issues here:

• What do you do when you launch the application? and
• How do you make sure the results and behavior match?

The first question is usually answered in terms of test data, use cases and automatic unit tests; he answers the second question by looking at the user interface of the application, as well as the results (data, web pages, reports) from both systems and comparing (for example, testing based on approval). Of course, testing tools can significantly improve efficiency. Large-scale migration is a very good time to discuss the possibility of using testing tools.

If you plan to migrate a large, complex code base, you need to plan a very smart testing process. If done correctly, a tool-based approach provides a very efficient off-the-shelf production code, and this will free up resources for creating quality control artifacts and improve quality control processes that will persist long after migration.

Disclaimer: I work for Great Migrations.

Answer 3

From the tone of your question, it sounds like you know the answer! I would say that everything except a complete set of regression tests will be a recipe for disaster! Ideally, you would like to run the same test suite with both the old and the new versions, although it looks like you can't do it ...

My honest answer is make sure you have many support / support developers willing to work around the clock with support support!