NovA generator bug is more dangerous than a one-page bug
Alexander Elshin on why shared templates, generators and data sources need separate testing: one defect can spread across hundreds of NovAsia pages.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
A typo on one page is local. A wrong rule inside a generator can reproduce itself across an entire catalogue.
NovAsia has large sets of Thailand project pages, developer profiles and connected content. When a shared component misreads a status, price or verification date, fixing the page where someone happened to notice it is not enough.
Test data states, not just URLs
A generator often fails at the edges of the data model. The normal record looks fine, while a missing value prints a placeholder, an unusually long name breaks the component, or an archived project is treated as current.
That is why a useful test set contains different states rather than ten examples that all look the same: a normal populated record, an empty optional field, a rare property type, an older record, and a value close to the boundary of whatever rule is being applied.
Testing ten ordinary pages can still be one test repeated ten times.
Find the layer that created the error
A local copy mistake can be fixed locally. A template or data-source mistake needs to be corrected at its origin, otherwise manual patches become a second source of truth.
The same principle applies to linked developer profiles such as the Eastern Star Real Estate page. A project list generated from a registry is useful because the relationship is systematic. If the selection rule is wrong, editing one profile by hand only hides the underlying fault.
I start by tracing the bad value backwards: was the source record wrong, did a transformation change it, or did the rendering rule interpret it incorrectly? Those are different failures and deserve different fixes.
Bulk changes need a representative preview
Before a generator touches a large set of pages, I prefer to inspect a small but deliberately varied sample. It should include edge cases, not simply the first records in a file.
That preview is where logic errors are cheapest to catch. After the full run, I still want a broad sanity check: expected page count, missing blocks, routing consistency and repeated errors that may have escaped the sample.
Automation is valuable because one correct rule can produce hundreds of consistent pages. Its failure mode is the mirror image: one bad rule scales faster than any editor could make the same mistake manually.
That is why I debug the rule and the source before patching the visible symptom one URL at a time.