Inherited a CFML Application With Few Tests? Here’s Where to Start!
You need to change an application that has been running for years.
It might be a ColdFusion customer portal, a Lucee application supporting internal operations, or a CFML system your team is preparing to modernize. People depend on it, but some of its behavior lives in old tickets, scattered documentation, and the memory of whoever has supported it longest.
Now a release is approaching.
You know more testing would help. The difficult part is deciding where to begin without putting every other priority on hold.
Start with one important workflow and build evidence around what it needs to do.
Choose the first workflow by business impact
Opening the codebase and testing the easiest function can help you learn a testing framework. For release planning, choose something that matters to the business.
Ask the people who use and support the application:
- Which failure would prevent someone from completing important work?
- Which workflow has caused incidents or repeated support requests?
- Which area will the upcoming release change?
- Where would incorrect data be difficult to detect or repair?
Look for a workflow where business importance overlaps with an upcoming change or known uncertainty.
For this article, consider a fictional customer portal where users submit orders. An order is saved, appears in an approval queue, and triggers a confirmation email.
“Order submission works” is too broad to test reliably. Break it into observable outcomes.
Write down what success means
For our sample workflow, a successful submission might require:
| Check | Expected outcome |
|---|---|
| Authorized customer submits a valid order | One order is created under the correct customer account. |
| Required information is missing | The application explains the problem and does not create an incomplete order. |
| User tries to submit under another customer’s account | The request is rejected and no order is created. |
| Confirmation email cannot be sent | The order follows the agreed business rule, and the notification failure is recorded. |
| User repeats the submission | The system follows the agreed duplicate-submission rule. |
The last two checks require a business decision.
Should an email failure prevent the order from being accepted? Should a repeated submission create another order, return the existing one, or show a warning?
If the team cannot answer, you have found a requirement to resolve before you automate the check.
Explore Ortus Quality Assurance Services
Capture current behavior, then decide what to preserve
An existing application may behave differently from what people expect.
Run the selected workflow in a controlled test environment. Record the inputs, user role, output, saved data, and relevant side effects.
These observations can become characterization tests: tests that describe what the application currently does.
However, current behavior is not automatically correct behavior.
If the application saves an incorrect total today, preserving that result in a passing test would protect a defect. Mark uncertain behavior for review with the relevant business owner.
Keep a simple record:
Observed behavior → agreed behavior → test needed
That distinction matters when documentation is incomplete.
Test more than the page response
A confirmation page is one piece of evidence.
For our order example, verify that the saved record belongs to the correct customer, contains the expected items and totals, and appears in the appropriate approval queue.
For a rejected request, verify the absence of unintended changes. An error message does not prove the application avoided saving a partial record.
Follow the workflow through the parts of the system that determine its outcome.
Explore Ortus Quality Assurance Services
Put each check where it gives useful feedback
You do not need to exercise every rule through a browser.
A calculation can be checked at the service level. Database persistence needs a test that exercises the database interaction. A browser check can verify that a user can complete the journey through the interface.
For CFML teams, TestBox provides testing capabilities including assertions, expectations, runners, and MockBox for mocking and stubbing. It can support focused automated checks as your coverage grows. TestBox documentation.
Choose the test level based on what you need to prove.
A mocked email service can help check how your application responds when sending fails. It cannot establish that the real email integration is configured correctly. That needs a separate integration check.
Make the test repeatable
Before calling the check reusable, define its setup:
- Which test account and permissions does it require?
- Which records must exist?
- How will each run use identifiable test data?
- How will created data be cleaned up?
- How will you prevent real customer notifications or transactions?
For the sample order workflow, use controlled accounts and a designated test notification destination. Avoid relying on a shared record that someone else may edit between runs.
Record the runtime version and relevant configuration as well. That makes results more useful when investigating a failure or preparing an upgrade.
Use the evidence in the next release
Once the initial checks are reliable, make them part of the release process.
Assign an owner, define when they run, and agree on how failures will be handled. For example, a failure that allows an order to be saved under the wrong customer account should prevent release until it is resolved.
Keep exploratory testing alongside these checks. Automated tests verify the expectations you encoded; people still need to investigate behavior beyond those expectations.
After the release, add coverage based on what you learned: a newly discovered edge case, a changed business rule, or a production defect that the existing checks missed.
Your first step this week
Choose one important workflow.
Write down its successful outcome, one invalid-input case, one permission case, and one dependency-failure case. Identify the data and environment needed to repeat those checks.
You now have a defined starting point for QA, and a clearer view of the questions your next release needs to answer.
Need help choosing where to start?
Tell us about your CFML application, your next release, and where your team needs more confidence. Ortus can help you identify QA gaps and prioritize practical next steps.
Explore Ortus Quality Assurance Services
Stay Connected with the Ortus Solutions Ecosystem
Stay connected with Ortus Solutions and get the latest updates delivered to you.
Subscribe to Our Newsletter
Get the latest product releases, technical articles, tutorials, upcoming events, and exclusive content delivered straight to your inbox.
Join Our Developer Community
Connect with fellow developers, ask questions, share ideas, and engage directly with the Ortus team. Join our community to stay involved in the conversations shaping the ecosystem.
Join the BoxTeam Community on Slack
Follow Us on Social Media
Stay up to date with our latest announcements, releases, educational content, and community news. Follow Ortus Solutions on your favorite platforms:
Add Your Comment