The test that passes while the application still behaves differently
A migrated Oracle Forms application can render correctly, import cleanly, and still behave in ways that matter to the people using it. That gap is the subject of this interview with Mattias Fagerlund, whose work at FormsRefresh involves converting Forms applications to native APEX and then checking whether the rebuilt application actually matches the original.
He described a pattern that has repeated across projects: "We've had an LLM convert many Forms applications to native APEX, and every generated app looked right. The pages rendered and the export imported cleanly. What showed the gaps was running the same scenarios on both apps, the Forms original and the APEX rebuild."
Two examples illustrate the problem. In the first, an Interactive Grid commits an edited cell a moment after it loses focus. A user who clicks Save quickly loses the change, and the unsaved-changes warning never appears. On the Forms original, the change is saved. In the second, links inside a modal dialog were rewritten by APEX to close the dialog and navigate the page behind it, so the user lost what they were doing.
Neither issue is visible in a page-by-page review. As Fagerlund put it, "Neither of these is a bug you can see in the code. You only see them by comparing what the old app and the new app actually do."
The behaviour nobody wrote down
When comparing Forms and APEX screens, Fagerlund keeps returning to behaviour that Forms handled automatically and that no specification captured. Row order is one: many Forms blocks have no ORDER BY, so users see rows in whatever order Forms happens to fetch them, and they are used to that order. APEX can return the same rows in a different order.
Dates are another. A Forms date item often holds only the day, while the rebuilt page stores the time as well, so a later comparison or report gives a different answer. The same category includes where the cursor goes, which message appears and in what words, and what happens when a user leaves a record with unsaved changes.
There is also the database side. "The screen can match perfectly while the rows written behind it differ. We compare both," he said.
Not every difference needs fixing. Fagerlund is explicit that a grid's keyboard behaviour will not match Forms, and that nobody should rebuild Forms inside APEX. The point, he argues, is to decide such differences on purpose and write down why.
Three assumptions teams settle too quickly
The first is that the test cases are complete. Test cases written from documentation or from what users remember cover what people know. Fagerlund's alternative is to record what the running original actually does and to measure which triggers and program units the scenarios actually reach.
The second is which differences are acceptable. Formatting such as "42.5" versus "42.50", timestamps, and row order all need agreed tolerances before the comparison, not after, so they do not stretch to cover a real defect.
The third is that a passing test suite means a sound one. "We check ours by planting small defects in the migrated app. Our scenarios catch most of them, but not all, and each miss tells us which scenario to add," he said.
What this means for teams weighing testing tools
For anyone assessing Oracle Forms migration testing tools, the practical takeaway is that visual inspection and clean imports are weak evidence. The useful signal comes from running the same scenarios against both applications and comparing what each one does, including the rows written to the database.
It also helps to treat the test suite itself as something to be tested. Planting small defects and tracking which ones slip through turns a passing suite into a measurement rather than an assumption.
Fagerlund's answers point to a discipline that is less about tooling categories and more about comparison: record the original's behaviour, agree tolerances in advance, and check both the screen and the data behind it. For teams working through a Forms to APEX migration, that is a concrete way to catch the differences that a green test run will not show.