Testing AI-generated code: how do you know it actually works?

AI makes generating code easy

If you use AI for IT work, this probably sounds familiar. You describe what you need, get a suggestion and make a few adjustments. Before you know it, you have a script or function that might have taken you much longer to write yourself.

• A system administrator asks AI to write a PowerShell script to clean up old files.
• An IT colleague builds an integration that transfers data from Excel into another system.
• A developer generates a discount function.
• A Scrum team asks AI to prepare tests for the next user story.

Useful. But then comes the question: how do you check whether what AI has created actually works? Generating something and demonstrating that it works are two separate steps.

Take the system administrator’s cleanup script. It needs to delete files that are more than ninety days old. That sounds straightforward. Still, you’ll want to know:

• Which date does the script use: the creation date or the last modified date?
• What happens to files that are exactly ninety days old?
• Are subfolders included?
• Are important folders excluded?
• Can you preview what the script would delete?

These questions help you decide whether you can use the script with confidence. “It ran without an error message” only tells you part of the story.

What does testing AI-generated code mean?

Testing AI-generated code means investigating whether the solution does what you need under the conditions that matter to you. You might check whether a script selects the right files, an integration processes data correctly or a function performs the agreed calculation.

You can do this by reading and assessing the code. That’s called a code review. You can also run the solution with selected data and compare the outcome with what you expect. Within TMap, these activities fall under static and dynamic testing. Both help you gather information about quality.

This article focuses on code created with AI. Testing an AI model or chatbot itself raises additional questions.

Why passing AI-generated tests may not be enough

Imagine a developer asks AI to build a discount function. The requirement is:

• A customer receives a 10% discount, capped at €25 per order.

AI writes the function and creates tests for it. An order of €50 gets a €5 discount. An order of €100 gets €10 off. All the tests pass.

Great. Until someone places a €400 order. The function gives them a €40 discount. The cap has been forgotten. A nice surprise for the customer, slightly less so for the finance team.

This shows how code and tests can follow the same incorrect assumption. The tests check the percentage calculation, but not the discount cap. So the question for every test is: what are we basing the expected result on? An agreed rule, or whatever the generated code happens to do?

Even a high percentage of code coverage doesn’t fully answer that question. It shows which code was executed during testing. It doesn’t prove that all important requirements have been implemented correctly.

Start with clear requirements and quality risks

Before generating more tests, you need to be clear about what “works” means. There may be additional rules for the discount function. Does the discount apply to every product? Can customers combine it with a discount code? How should amounts be rounded?

An integration between Excel and a customer management system raises different questions. What happens with duplicate customer records? Empty fields? Or an import that stops halfway through?

Describe the desired behaviour in clear, testable terms. In a Scrum team, you’ll often use acceptance criteria. For an administration script, a short description with examples may be enough.

Next, look at the quality risks: what could go wrong, and what would the consequences be?

Incorrect text on a screen needs different attention from a script that deletes files. TMap helps you make that judgement and adjust your testing effort accordingly. This allows you to spend your time on checks that matter.

Checking AI-generated code: four practical things to look at

1. Does the solution do what was agreed?

Read the code alongside the requirements. Have conditions and exceptions been included? Has AI filled in any gaps by making its own choices? If you don’t understand how an important part works, investigate it further. An explanation from AI can help, but check it against the code and its behaviour.

2. What happens when something unexpected occurs?

A file is missing. A user enters an unexpected value. A connected system doesn’t respond. These are everyday situations. Investigate how the solution handles them. Does it display a clear message? Can you recover? Has any data already been changed before something goes wrong?

3. Does the code fit your environment?

Check whether the functions and software versions used are compatible with your systems. A script that works locally may behave differently on another server because of permissions, settings or available components. For integrations, you’ll also want to know whether data is exchanged in the correct format. Integration testing helps you investigate how those parts work together.

4. Can your team use and maintain the solution safely?

Look at access permissions, sensitive data and the ability to undo changes. Think about the next colleague who will work with it, too. Will they understand what the code does? Have important decisions been explained? Code that was quick to generate needs to remain useful later on.

How do you test AI-generated code using good examples?

You don’t need to create dozens of tests straight away. Start with situations that investigate important rules and risks.

For the discount function—a customer receives 10% off, capped at €25 per order—these are useful examples:

Amounts just below and above €250 can provide additional information. That’s the idea behind boundary value analysis.

For the cleanup script, you might select recent files, old files and files in an excluded folder. Test with a manageable set of test files before letting the script loose on real ones.

Feel free to let AI help you come up with test situations. Then assess whether those situations are relevant and whether the expected outcomes are correct.

AI code quality is a team responsibility

In a cross-functional team, one person doesn’t need to have all the answers. The developer understands the implementation. The tester investigates missing scenarios. The product owner clarifies business rules. The system administrator knows which permissions and settings apply in practice.

Combining that knowledge helps bring assumptions to light earlier. Agree on who will carry out which checks and what information you need to move forward.

A short checklist can help when reviewing a pull request:

• Is it clear what the change should do?
• Have the main risks been discussed?
• Do we understand the solution?
• Are expected results based on agreed requirements?
• Have relevant exceptions and errors been investigated?
• Do we know which questions remain unanswered?

TMap helps you build confidence in what AI creates

AI makes it easy to generate something. TMap helps you investigate whether it works as intended. You start with clear requirements, discuss risks, choose suitable checks and assess the results. That gives you a stronger basis than a convincing code suggestion or a passing test result alone. Want to learn how to do this together with your team? Our TMap® Quality for cross-functional teams e-learning explores the quality principles that help you do just that. So, with your next AI-generated solution, you’ll be better equipped to answer: what have we checked, and why do we trust it?