Episode 5: AI-Ready Engineering: Tests Are Instructions for Humans and AI
We usually talk about tests as protection. They catch regressions, build confidence, and stop someone from accidentally breaking production on a Friday afternoon. In an AI-assisted NetSuite codebase, tests pick up a second job: they explain what the system considers correct.
In Episode 4, “Let the Variables Tell the Story,” we looked at how names can carry a codebase’s business meaning. This episode looks at tests, the part of the codebase that can prove whether that meaning still holds.
What: A Good Test Suite Is Executable Context
Imagine asking an AI tool to change a user event script that validates vendor bills. It reads the implementation, the function signatures, and the calling code. Then it opens the tests, and suddenly it knows things the script alone doesn’t make obvious.
A well-written suite shows which inputs matter, which edge cases exist, and which behaviors are deliberate. It shows what must stay the same no matter how the code is rewritten. Unlike documentation, tests also complain the moment reality stops matching the description, and we appreciate that level of commitment.
Why: Generated Code Needs an Independent Definition of Correctness
AI can generate code that is reasonable, readable, and completely wrong for your system. It compiles, the naming looks good, and there is even an elegant helper function. It just broke a subsidiary rule nobody mentioned.
Reviewing generated code without tests mostly means reading it and asking whether it looks right. That is a weak safety net, because AI-generated code tends to look very convincing.
Tests let us ask whether the system still behaves the way we said it should.
That question has an answer we can check, regardless of how sensible the new code appears.
It also turns surprises into useful conversations. If an AI tool changes a function and ten tests fail, the code may be wrong, the tests may be outdated, or the requirement may have changed. Either way, the team is now discussing observable behavior instead of running on vibes.
Example: Same Check, Two Very Different Tests
Before: the test passes, but it teaches nothing.
test('test case 1', () => {
expect(validateBill(bill1)).toBe(false);
});
After: the test name states the business rule.
test('should reject vendor bill when subsidiary does not match vendor', () => {
const bill = buildBill({ subsidiary: 'US', vendorSubsidiaries: ['CA'] });
expect(validateBill(bill).valid).toBe(false);
});
Both tests may protect the same line of code. Only the second tells a new engineer, a reviewer, or an AI tool what the rule is and why it exists.
How: Write Tests That Explain the Business
A suite with hundreds of shallow tests can still say very little about what the system is supposed to do. The most valuable tests describe behavior.
Test outcomes over implementation details
If a refactor breaks every test while the behavior stays the same, the tests are too tied to the implementation. Good tests leave room to change how something works while protecting what it promises. That matters even more once AI starts proposing refactors.
Make test names meaningful
A test called testCase1 tells the next reader nothing, so please don’t. A good test name states the rule being protected, like the one in the example above. Before anyone reads the body, that test is already teaching domain knowledge.
Capture edge cases
Happy paths are easy to test, and systems usually get interesting everywhere else. Missing values, unexpected statuses, duplicates, retries, and invalid transitions are where the real boundaries live. Tests for those scenarios show both humans and AI where the system draws its lines.
Test business rules explicitly
If a rule matters to the business, give it its own test. A rule buried inside a giant integration test is easy to miss six months from now. Put important behavior where people and tools will find it.
Write platform limits down as tests
Governance usage, script timeouts, and records that arrive through CSV imports or integrations instead of the UI are all edge cases worth encoding. Oracle’s SuiteCloud unit testing package runs Jest tests against stubbed SuiteScript modules, so teams can test logic without deploying to an account first.
Treat failing tests as information
When AI changes something and a test fails, resist the urge to immediately fix the test right away. Sometimes the test really is outdated. Other times it is the only remaining evidence that the new code quietly broke an old requirement. Treat a failure as a question and answer it before deleting anything.
What “Correct” Means
NetSuite projects are full of rules an AI tool cannot infer from syntax: subsidiary restrictions, approval routing, and record status transitions. A test named for the rule tells the tool, and the reviewer, what any change has to respect. Tests have always been part of good engineering. AI just makes another benefit obvious: they are instructions for the next engineer, the reviewer, and the tool.
When code can be generated in seconds, knowing whether it is right becomes the valuable part.
At ATSOURCE, we build NetSuite teams that define correct behavior before they change it, so every reader of the code, whether a new engineer or an AI tool, knows what correct means. Let’s talk about what that looks like for your organization.
Meet the Author
Jona has over a decade of experience in SuiteCloud Development on the NetSuite platform. She specializes in implementing advanced solutions and has led teams in creating high-quality software. Jona holds multiple certifications and has been recognized with awards like the Summit Award and Quality Champion Award.
Tags
Accelerate ERP Success with Expert Solutions
Ready to put what you've learned into practice? ATSOURCE delivers both the specialized talent and comprehensive NetSuite support you need to turn strategy into results.Connect with our experts today and move from planning to performance.
