What is unit testing?

Unit testing checks the smallest testable parts of a product, such as a single module, component or function, on their own. The goal is to find problems while they are small and easy to trace, before the parts are joined together.

Can unit testing be done manually?

Yes, at the component level. Our QA engineers test each module by hand, in isolation, through its own screen, API endpoint or a simple test harness, using stubs for anything it depends on. Checks that should run on every build are then turned into coded unit tests.

What is the difference between manual component testing and coded unit tests?

Manual component testing uses a tester’s judgement to explore a module’s behaviour, rules and edge cases. Coded unit tests repeat specific checks automatically on every build. Manual testing finds problems; coded tests stop them coming back.

Isn’t unit testing the developers’ job?

Developers usually write most coded unit tests. QA adds an independent view: testing components by hand as they are finished, spotting missing cases, reviewing test quality and writing tests for high-risk code when the team is short of time.

How is unit testing different from integration testing?

Unit testing checks one module on its own, with its dependencies stubbed. Integration testing checks that modules and systems work together. Both are needed; unit-level checks make integration problems much easier to trace.

Which languages do you work with?

We work with JavaScript and TypeScript, Java, Python, C# and .NET, PHP, Go, Kotlin, Swift and Ruby, and the common unit test frameworks for each, such as Jest, Vitest, JUnit, TestNG, Pytest, NUnit, xUnit and PHPUnit.

What code coverage should we aim for?

There is no single right number. We set targets per area: higher for business rules, calculations and security code, lower for simple or generated code. A focused 70% on what matters beats 95% that skips the risky parts.

What is mutation testing?

Mutation testing makes small, deliberate changes to your code and checks whether your tests notice. If a change survives, the tests aren’t really protecting that code. It is the best way to judge test quality, not just quantity.

Can you add unit tests to old code with none?

Yes. We first record how the code behaves today with manual checks and characterisation tests, then add tests around the riskiest areas so the code can be changed safely.

Do you help with test-driven development?

Yes. We help write the first tests from the requirements, suggest edge cases before code is written and pair with developers until the team is comfortable with the practice.

Can unit tests run in our CI pipeline?

Yes. We set up unit tests in GitHub Actions, Jenkins or your CI, with coverage reports and gates that stop untested changes from being merged.

Do you test front-end components?

Yes. We test buttons, forms and widgets by hand in every state, and write coded component tests with Jest or Vitest where they add value.

A module and risk map, a unit test strategy, component test results and bug reports, coded unit tests in your repository where agreed, CI and coverage set-up, and a regular coverage and quality summary.

Unit Testing Services

The easiest bug to fix is one found in a single module, before it is tangled up with everything else.

Our QA engineers test each module and component by hand, on its own, as soon as it is ready. Where a check should run on every build, we help turn it into a coded unit test your developers can keep. You get problems found early, honest coverage and code that is safer to change.

Get in touch Plan your unit testing

Manual component testing
Coded tests where needed
9 languages
Free one-week POC

What we do

Manual component testingBy hand, in isolation Unit test strategyAgreed rules Coverage analysisKnow what’s untested Coded unit testsCoded, when needed TDD supportTests first MockingTrue isolation Legacy codeChange without fear CI and coverage gatesEvery build Mutation testingTest the tests Front-end componentsUI building blocks Reviews and coachingBetter tests over time

[ Why unit testing ]

Find it in one module, not in the whole product

When a bug is found after everything has been put together, it can take hours just to work out where it came from. Testing each module on its own, as soon as it is ready, makes problems obvious and cheap to fix. Developers often don’t have time to do this carefully for every piece. Our QA engineers do it by hand, with a tester’s eye for edge cases, and help your team build coded unit tests where repeating a check automatically really pays off.

Languages: JavaScript and TypeScript, Java, Python, C# and .NET, PHP, Go, Kotlin, Swift and Ruby. Next step up: integration testing →

Bugs found while they’re small

Each component checked before it is joined to others, so problems are easy to trace and cheap to fix.

Clear on what’s tested

Manual checks and coded tests mapped to each module, with honest coverage.

Safer changes

Safety nets around risky code, so refactors and upgrades don’t surprise you.

Developers keep moving

QA takes on the careful, repetitive checking, so developers can focus on building.

[ What we test ]

Manual component testing first, coded unit tests where they pay off

Eleven services, starting with hands-on testing of each module. Each one lists what we do, when you need it and the problem it prevents.

Manual component testing

By hand, in isolation

Our QA engineers test each module or component on its own, before it is joined to the rest of the product, so problems are found while they are small and easy to trace.

What we test

Each module tested through its own screen, endpoint or test harness
Inputs, outputs, rules and calculations checked one by one
Boundary values, empty and invalid data
Stubs used so other modules don’t hide or cause failures

When you need it

As each module or feature is finished, before integration.

The problem it preventsBugs found weeks later, buried under three other modules

Unit test strategy & standards

Agreed rules

A short, practical agreement on what gets tested at unit level, by hand or in code, and what “good enough” looks like for your team.

What we test

What to test manually, what to code and what to skip
Naming, structure and review rules for unit tests
Sensible coverage targets per area, not one number for all
A checklist developers and testers can both use

When you need it

When starting a project, or when testing feels inconsistent.

The problem it preventsEvery developer testing differently, or not at all

Coverage analysis & gap filling

Know what’s untested

We measure what your current tests really cover, find the risky gaps and fill them first, by hand or with new tests.

What we test

Coverage reports read and explained in plain words
Untested business rules and error paths listed
Gaps ranked by risk, not by percentage
Gaps filled with manual checks or new unit tests

When you need it

Before a big release, refactor or audit.

The problem it preventsA high coverage number that hides untested critical code

Writing unit tests for existing code

Coded, when needed

Where a check should run on every build, our engineers turn it into a coded unit test that your developers can read and maintain.

What we test

Tests written in your language and framework
Clear names that explain the expected behaviour
Fast, independent tests with no hidden dependencies
Reviewed with your developers before merge

When you need it

For stable, high-risk code that changes often.

The problem it preventsThe same manual check repeated by hand every release

Test-driven development support

Tests first

For teams adopting TDD, we help write the first tests from the requirements, so developers build against clear, agreed behaviour.

What we test

Acceptance examples turned into unit-level cases
Edge cases suggested before code is written
Pairing sessions with developers
Gradual hand-over so the team owns the practice

When you need it

When a team wants to start or improve TDD.

The problem it preventsRequirements that are clear to nobody until the code is wrong

Mocking & test doubles

True isolation

Mocks, stubs and fakes that let a component be tested on its own, by hand or in code, without real databases, services or payments.

What we test

Stubbed services and sample responses for manual checks
Mocks and fakes in your unit test framework
Error, timeout and edge responses on demand
Mocks kept honest against the real behaviour

When you need it

Whenever a component depends on things that are slow, costly or unavailable.

The problem it preventsTests that fail because something else is down

Legacy code safety nets

Change without fear

Before older code is changed, we capture how it behaves today, so any change in behaviour is spotted straight away.

What we test

Current behaviour recorded with manual checks and characterisation tests
Risky areas mapped before refactoring
Safety net run after every change
Gradual improvement, not a big rewrite

When you need it

Before refactoring, upgrades or taking over an old codebase.

The problem it preventsA “small clean-up” that quietly changes business rules

Unit tests in CI/CD with coverage gates

Every build

View service

Coded unit tests run automatically on every pull request, with coverage gates that stop untested changes from merging.

What we test

Unit tests running in GitHub Actions, Jenkins or your CI
Coverage reports with Codecov, JaCoCo or SonarQube
Gates on new code, so coverage never slips
Fast feedback, with flaky tests found and fixed

When you need it

Once you have a base of coded unit tests.

The problem it preventsUntested code merged because nobody noticed

Mutation testing

Test the tests

Mutation testing changes your code on purpose and checks whether your tests notice. It shows which tests really protect you.

What we test

Mutation runs with Stryker or PIT on key modules
Surviving mutants explained in plain words
Weak tests strengthened or replaced
Focused on critical code, not the whole codebase

When you need it

When coverage is high but bugs still get through.

The problem it preventsTests that run green no matter what the code does

Front-end component testing

UI building blocks

Buttons, forms and widgets tested on their own, by hand and in code, before they appear across your product.

What we test

Each component checked by hand in every state and variant
Props, events and edge cases
Coded component tests with Jest or Vitest
Changes checked for knock-on effects

When you need it

For component libraries and shared UI.

The problem it preventsOne broken component repeated on every screen

Unit test reviews & developer coaching

Better tests over time

We review your existing unit tests and help developers write clearer, more useful ones.

What we test

Review of test quality, naming and coverage
Missing cases and over-mocked tests flagged
Short, practical coaching sessions
Before-and-after examples from your own code

When you need it

When tests exist but nobody trusts them.

The problem it preventsA large test suite that slows the team down and still misses bugs

[ Manual component testing vs coded unit tests ]

Two ways to test a unit, and where integration begins

Manual testing finds problems; coded tests stop them coming back. Here is how they differ, and what a manual component checklist looks like.

	Question it answers	Who does it	How
Manual component testing	Does this module behave correctly on its own?	QA engineers, by hand	Each module through its screen, endpoint or harness
Coded unit tests	Does this code still behave the same on every build?	Developers and our engineers	Functions and classes, automatically
Integration testing	Do the modules work together?	QA and developers	Connections between modules and systems

Sample component checklistManual, in isolation

Component: Discount calculator (checkout module)
Isolated by: Stubbed cart and price services
Checks: 10% code on £100 → £90 · expired code rejected · two codes not combined
Edges: £0 cart · £0.01 item · code in lower case · 1,000 items
Expected: Totals rounded to 2 decimals; clear error for invalid codes
Result: Pass / Fail per check, with notes

Example only. Real checklists follow your modules and rules.

[ How we work ]

Six steps from first module to every build

We start by hand, prove value on real modules, then code only the checks worth repeating.

Step 1 of 6
Understand the code and risks

Modules, business rules, current tests and coverage reviewed with your developers.

You getModule and risk map
Step 2 of 6
Agree the approach

What to test by hand, what to code, and sensible coverage targets per area.

You getUnit test strategy
Step 3 of 6
Test components by hand

Each module tested in isolation as it is finished, with stubs where needed.

You getComponent test resultsBug reports
Step 4 of 6
Code what should repeat

Stable, high-risk checks turned into unit tests in your framework.

You getUnit tests in your repo
Step 5 of 6
Run on every build

Unit tests and coverage gates in your CI.

You getCI pipeline and coverage reports
Step 6 of 6
Review and improve

Gaps, weak tests and flaky tests reviewed regularly.

You getCoverage and quality summary

Free one-week POCWe test one important module by hand, review its tests and show you the gaps.
Your code, your rulesCoded tests follow your style, live in your repo and go through your reviews.
NDA before accessWe sign your NDA before we see any code.

[ Tools ]