Unit tests are often the first visible sign of code quality. If you search for “unit tests”, you usually want to understand what tests actually show, how reliable they are as a signal, and where their limits lie.
For engineering leads, unit tests are an obvious work sample because they can make thinking, care and the handling of change visible. For developers, they are a way not just to claim quality, but to show it through real work, for example in the context of real repository work.
This article puts unit tests in context as part of a work sample: neither as a mere formality nor as proof on their own. What matters is
- what exactly is being tested,
- how the tests came about,
- and the technical context they sit in.
What unit tests actually show as a work sample
Unit tests check small, clearly defined units of behaviour in code. That makes them interesting as a work sample, because they do not just document an outcome, but often also show how someone breaks a problem down and translates it into behaviour that can be verified.
You can read more from them than simply “tests are present”:
- Are edge cases taken into account?
- Are preconditions stated clearly?
- Is the expected behaviour described precisely?
- Are failure cases considered deliberately?
These points say something about working style, care and quality awareness. For reviewers in particular, this is often more tangible than any claim on a CV, because tests are tied to concrete decisions in the code.
At the same time, unit tests have clear limits. They do not automatically show whether architectural decisions are sound, how secure a project is, or whether dependencies introduce risks. If you want to understand how this assessment can be brought together in a broader review, you can find the structure in the Proof Engine methodology.
The sheer number of tests is not a reliable signal either. Many superficial tests can be less meaningful than a few carefully chosen tests with a clear focus. What matters is not volume, but whether the tests provide orientation: around intent, risks and relevant behaviour.
That is why unit tests should never be read in isolation. They only become meaningful alongside the implementation, commit history and technical environment. If you want to assess contributions in the history more accurately, it often helps to look at Git context in practice.
For teams that want to review this kind of evidence, verification for companies is relevant; the practical framework for it is set out in pricing for audit and verification.
How to recognise strong and weak unit tests
Good unit tests are, first and foremost, understandable. It should be clear as soon as you read them what behaviour is being checked, under what conditions it applies, and why that specific case matters. If a test only becomes understandable after prolonged deciphering, it loses value as a work sample.
Meaningful tests also do not stop at the standard case. They check what happens at the edges as well:
- failure cases
- boundary values
- typical special conditions
- unexpected inputs
This is often where you can tell whether someone has really thought the behaviour through or has simply covered the obvious happy path.
Another strong signal is when tests deliberately accompany changes and keep behaviour stable. Tests like these protect intent. Less helpful are tests that mainly reproduce current implementation details. They then break as soon as the internals are reworked, even though the business behaviour has stayed the same. As a work sample, that makes them look fragile.
Weak unit tests can often be recognised from recurring patterns. These include hard-to-read names, many indirect assumptions, unnecessarily complex setups, or assertions that basically just mirror the existing code line by line. Excessive mocking is also a warning sign if, in the end, it is more the test construction that is being checked than the actual business behaviour.
Test coverage is useful here, but it is not the same thing as test quality. High coverage can be misleading if critical paths, error handling or security-relevant areas are hardly tested in any meaningful way. The number alone therefore does not answer how robust the test set really is.
So if you assess unit tests as a work sample, you should not just ask whether tests are present. More important is whether they provide orientation: around intent, risks and the robustness of the code. And if the question is about individual changes or responsibilities, it also helps to look at the history.
Why unit tests are easy to misread without their context
Unit tests are only reliable as a work sample if it is also visible how they came about. A clean-looking test set can be convincing at first glance and still leave open who actually did the work.
That is why the final state of a repository is often not enough for a proper assessment. What matters is the course of events in Git:
- Who authored the commits?
- How did tests and implementation evolve together?
- Did the changes emerge in understandable small steps?
Only this context turns tests into more than a static artefact. Without it, it remains unclear whether tests were really part of the development work or were only added later.
Assessment becomes harder when code or tests enter a repository in larger blocks. At that point, it is hardly possible to see how decisions came about, what thinking sat behind individual changes, and what specific contribution a person actually made.
This is exactly where Stage A comes in at Acquispect. The Ghostwriter Detector analyses the .git history forensically. It looks at authorship, searches for code dumps, and produces an Impact Score.
For assessing unit tests, this is a useful addition. What matters is not just that tests are present, but also whether they grew organically with the implementation and can be traced as part of real work.
For engineering leads, this matters because otherwise a work sample can easily be read only as a finished result. But software development shows itself not just in the result, but in the process.
The same applies to developers from the other direction. Good work often becomes visible precisely where changes are structured cleanly, documented clearly and traceable in how they developed — not just in the final state of a repository.
So if you assess unit tests, you should always read their origin as well.
Unit tests in combination with security, tech stack and review
Even when they are well written, unit tests only answer part of the quality question. A repository can look solid at test level and still contain risks elsewhere that are barely visible in the tests.
That is why it is worth reading the adjacent signals as well. These include, above all, questions such as:
- Were secrets accidentally committed to the repository?
- Are there known vulnerabilities in dependencies?
- Is the test coverage meaningful in context?
- Does the chosen tech stack look understandable and consistent?
At Acquispect, this is handled by Stage B, the Safety Check. It scans for leaked secrets, known vulnerabilities in dependencies, test coverage and the tech stack in use.
For engineering leads, this extra view matters because unit tests can otherwise easily be overrated. Tests show care in the small: whether behaviour is described precisely, changes are safeguarded and edge cases are considered. But they do not automatically say what the security and maintenance reality of the whole project looks like.
There is another point as well: a work sample needs not just measurement points, but interpretation. Different perspectives see different risks. Technical leadership looks at a repository differently from security, performance, architecture or craftsmanship.
That is why, in Stage C at Acquispect, a panel of five AI expert personas assesses the repository:
- Tech Lead
- Security
- Performance
- Architect
- Craftsman
These perspectives lead to a consensus verdict with a Confidence Score, not to an absolutely certain judgement.
This is exactly what allows unit tests to be put in context sensibly. They remain an important signal, but not the sole authority on quality. Only in combination with security, technical context and professional assessment does a more reliable picture emerge of what a work sample actually shows.
How developers can make good work evidencable with unit tests
For developers, the value of unit tests does not lie only in internal quality gains. They can also show how someone works: whether behaviour is described clearly, whether changes are safeguarded cleanly, and whether care is visible in day-to-day work.
This work sample becomes more convincing when tests are not read as an isolated code excerpt, but together with real repository history. Only then does it become visible how tests and implementation came about and how traceable the work is over time.
At Acquispect, the result of this review is sealed as a tamper-proof W3C Verifiable Credential based on did:web in the developer’s own wallet. The credential belongs to the developer.
During verification, a company does not see the raw data, but the verdict. It can also read the full audit log to understand the assessment.
Important in practice:
- The repo audit is free for developers.
- Companies pay per verification.
- There is no subscription.
Common questions about unit tests as a work sample
Are unit tests enough to assess a developer’s quality?
No. Unit tests show important aspects, but never the whole picture. They can make it visible whether someone describes behaviour clearly, thinks about edge cases and safeguards changes deliberately. That is valuable, but not enough on its own for a reliable assessment.
Otherwise, points such as these remain open:
- how secure a repository is overall
- whether dependencies introduce known risks
- how coherent the technical context is
- how traceably the work actually came about
That is why unit tests should be read as one signal among several, not as final proof.
Is high test coverage the same as good tests?
Again, no. High coverage can be useful because it shows which parts of the code are touched by tests. But it still does not say whether the important things are being checked.
Good tests protect relevant behaviour. Weaker tests sometimes only increase the numbers without saying much about robustness. What matters more is:
- Are failure cases checked?
- Are boundary values covered?
- Does the business intent remain understandable?
- Are implementation details merely being recreated?
Coverage is therefore a measurement point, but not a substitute for substantive assessment.
Why is Git history important when I assess unit tests?
Because tests are easy to overestimate without the context of how they came about. Only the history shows who authored commits, whether tests grew together with the implementation, and whether changes emerged traceably in steps.
At Acquispect, Stage A analyses the .git history forensically: authorship, code dumps and an Impact Score. That complements the view of the test code alone.
How can a company verify results without disclosing the whole repository?
Through selective verification. At Acquispect, the result is sealed as a W3C Verifiable Credential based on did:web in the developer’s wallet. The credential belongs to the developer.
During verification, a company sees the verdict rather than the raw data. It can also read the full audit log to understand how the assessment came about. The verdict itself is produced in Stage C by a panel of five AI expert personas and includes a Confidence Score.
Conclusion: unit tests are strong, but never decisive on their own
Unit tests are useful as a work sample if you do not read them in isolation. For assessing code quality, they answer one specific question: is relevant behaviour being protected deliberately, or is only the surface being tested?
A more reliable picture only emerges together with further context:
- Git history and authorship
- Safety Check for secrets, known vulnerabilities, test coverage and tech stack
- technical assessment by a panel of five AI expert personas
Read in that way, unit tests are an important signal — not as proof in themselves, but as part of traceable evidence from real repository work.