Unit tests can show whether code produces expected results for selected inputs, but they cannot prove who wrote it.
Understanding the difference between testing behavior, detecting AI authorship, and checking code similarity helps prevent test results from being treated as evidence they cannot provide.
What do unit tests actually show?
A unit test checks a small, defined part of a program, such as a function or class, under specified conditions.
It supplies inputs, compares the result with an expected outcome, and reports whether the check passed.
Tests can also verify that code handles edge cases, rejects invalid input, or raises an expected error.
These results describe behavior within the test's scope.
A passing test means the code behaved as expected for the cases that were run.
It does not mean the implementation is correct in every situation, and it does not identify the person or process that produced the implementation.
Humans and AI coding tools can produce code that passes the same tests.
Both can follow a specification, use familiar programming patterns, and make mistakes that tests fail to catch.
Test outcomes therefore do not provide a reliable authorship label.
Why passing tests cannot prove human authorship
Authorship is a claim about how code was created.
Unit tests are designed to evaluate what code does.
Those are different questions, and the test output does not contain a dependable record of the code's origin.
For example, a student might write a function by hand, use an AI assistant to draft it, or adapt a public example.
If each version returns the expected results for the tested inputs, the unit test may report the same outcome.
The test cannot distinguish among those histories.
The reverse is also true: a failing test does not show that AI wrote the code.
A person may misunderstand a requirement, overlook an edge case, or introduce a bug while editing.
AI-generated code can fail for similar reasons.
A failure is useful evidence of a behavior that needs attention, not evidence of authorship.
Can code style or test quality offer clues?
Reviewers sometimes look at naming, comments, consistency, test coverage, or the way a solution handles edge cases.
These details can help explain how a program is structured, but they are not conclusive indicators of who wrote it.
A person can produce unusually polished or inconsistent code; AI-assisted work can be edited to match an existing style.
Test quality has the same limitation.
Carefully chosen tests may suggest that someone understood the requirements, while missing tests may point to gaps in the development process.
Neither observation uniquely identifies a human or an AI tool.
Even a detailed test suite can be generated, adapted, or expanded by different contributors.
Context can make review more informative.
A code change alongside design notes, a sequence of commits, issue discussions, and an explanation from the developer gives a reviewer more material to assess.
Those records may support a conversation about the work, but they still need careful interpretation and are not automatic proof of authorship.
AI authorship detection and code similarity are different
AI authorship classification attempts to estimate whether content may have been generated by an AI system.
Code similarity or plagiarism checking instead looks for overlap between a submission and other code, such as public repositories or previously submitted work.
Similarity can prompt a closer review, but copied code may be human-written, and independently written code can resemble common solutions.
Neither category should be confused with unit testing.
A passing test does not establish originality, and a similarity match does not establish AI use.
Likewise, an AI detector's score is an estimate, not proof of authorship or misconduct.
Results should be considered alongside the method's limitations and relevant evidence.
Turnitin states that its AI writing model does not reliably detect code.
Its AI writing report should not be mistaken for a source-code similarity check.
These are distinct capabilities, and a result intended for prose should not be treated as a dependable assessment of programming authorship.
What can reviewers use instead?
When authorship matters, a fair review draws on multiple kinds of evidence and gives the developer an opportunity to explain the work.
Depending on the setting, useful material might include:
- Version history: Commits and revisions can show how a solution changed over time, although a commit record alone does not verify who composed every line.
- Design and debugging notes: Explanations of decisions, tradeoffs, and fixes can help a reviewer understand the developer's process.
- Code walkthroughs: Asking someone to explain a function, trace an example, or make a small change can assess their understanding of the code.
- Similarity review: A match can identify material worth examining, with attention to common patterns, attribution, and the circumstances of the overlap.
- Clear expectations: In a course or workplace, stated rules about AI assistance and attribution provide a basis for evaluating the process.
Each source has limits.
A walkthrough may demonstrate understanding without establishing who first typed the code.
Version history may omit work completed elsewhere.
Policies differ among schools, employers, publishers, and other organizations, so reviewers should check the rules that apply to their situation rather than assume one standard governs all cases.
Where does a source-code detector fit?
A source-code detector may offer an additional signal for a reviewer to investigate.
Codespy currently lists JavaScript, Python, Java, PHP, C/C++, and C# among its supported languages.
Any output from a detector should be treated as an indication to examine further, not as a definitive verdict.
A score alone cannot establish who wrote a program or whether a policy was violated.
Before relying on a detection result, reviewers should understand what the tool claims to analyze, what its result means, and what limitations apply.
They should avoid presenting an estimate as certainty and should not substitute a detector for the relevant evidence, an applicable policy, or a conversation with the person responsible for the code.
Use unit tests for the question they answer
Unit tests are valuable because they make expected software behavior explicit and help catch regressions as code changes.
They can show whether particular cases pass or fail.
They cannot show that code was written by a human, prove that it was written by AI, or settle a question of plagiarism.
For authorship concerns, use evidence suited to the question: examine the code's history and context, assess the developer's understanding, and interpret any detector or similarity result cautiously.
Keeping those roles separate makes technical testing more useful and authorship reviews more responsible.