Everything you know about application testing applies for legacy transformation projects, from unit tests to black/white box testing, test plan, et cetera… And when you are done with all these comes the hard part: proof of identity.
In order to understand testing in a legacy modernization project we have to understand how automated language conversion and modernization works and in which step testing takes place.
Application transformation is an iterative process. We take the legacy code, analyze, and parse it, convert to Java, build, test and when some tests don’t pass, we modify the conversion engine. The process looks like this.
We all know what code quality is. Mostly. Though we may have slight differences when we should tell if a certain piece of code is of good quality. Certain aspects we can measure, some other aspects call for aesthetical judgement or simply gut feelings. We can have rules and policies that developers must obey but I could not find one single document that exactly tells what good quality code looks like.
My own approach to score quality would revolve around how well a developer can communicate ideas to another developer who needs to read the code. This includes readability, concise and accurate comments, using meaningful names, code organization, layout on the surface, and proper componentization throughout the whole hierarchy of the application, clear interfaces and dependencies in the deep. Inherently the code must be performant and free from flaws (bugs, vulnerabilities). An application code on its own level must be self-documenting to achieve the above.
We at FreeSoft are in the language conversion business; for example, Cobol in, Java out. We’re talking about Cobol some guys wrote 20-30 years ago. I am not going to score these code pieces, but let’s take a look at what we can tell about the Java we create.
The promise of automated business rule extraction (BRE) from legacy systems and re-use in Business Rule Engines has been here with us for decades. Without killing the joke, we can safely assert, this has – similar to other promises of complex information processing solutions e.g., automated language translations, – always been just a few years away.
What is BRE?
Business rule extraction is a process of analyzing a piece of legacy application and creating a description of “what it does”. The “what” part includes context, use cases, functionality, data being processed, interactions, I/O, computational formulae, boundaries, constraints, etc. Everything that is necessary to be able to reproduce the exact functionality in its entirety in a new environment.
The output of such an endeavor is in any format, usually diagrams and plain English, as formal as possible. As if it was a system plan to begin with.
These business rules take on their meaning when they become part of business processes.