Testing Approaches

An approach is how you design and drive tests, independent of what you test. Two axes matter most: how much of the implementation you can see, and when you write the test relative to the code.

By knowledge of the implementation

Approach	You see	Typical use	Weakness
Black-box	Only inputs and outputs	Acceptance, E2E, API, functional tests	Misses untested internal branches
White-box	The source code and structure	Unit tests, coverage-, mutation-driven tests	Can over-fit to implementation
Grey-box	Some internal state/logs	Integration tests, security testing	Requires discipline to stay useful

Black-box

You treat the system as an opaque box: given this input, expect that output. Tests survive refactors because they never touch internals.

1
import { test, expect } from 'vitest';
2

3
// No knowledge of how `add` is implemented.
4
test('add sums two numbers', () => {
5
  expect(add(2, 3)).toBe(5);
6
});

1
def test_add_sums_two_numbers():
2
    assert add(2, 3) == 5

1
func TestAdd(t *testing.T) {
2
  if Add(2, 3) != 5 {
3
    t.Fatalf("want 5, got %d", Add(2, 3))
4
  }
5
}

1
@Test
2
void addSumsTwoNumbers() {
3
  assertEquals(5, calc.add(2, 3));
4
}

1
[Fact]
2
public void Add_SumsTwoNumbers() {
3
  Assert.Equal(5, Calc.Add(2, 3));
4
}

White-box

You inspect structure. Coverage tools and mutation testing live here; so do tests that deliberately exercise a specific branch.

1
// White-box: we assert on the internal branch we just wrote.
2
if (items.length === 0) return { total: 0, empty: true };

Grey-box

Partially informed by internals — e.g. an integration test that seeds a database directly, or a security test that reads the app’s logs.

By when you write the test

Practice	Meaning	Cycle
TDD — Test-Driven Development	Write a failing test, make it pass, refactor	Red → Green → Refactor
BDD — Behaviour-Driven Development	Tests written as plain-language scenarios (`Given/When/Then`)	Feature → Scenarios → Steps
ATDD — Acceptance-Test-Driven Development	Acceptance criteria written as tests before coding	Criteria → Test → Code
Test-after	Tests written after the code	Risky: the code “defines” correctness

TDD

1
1. RED    — write a test that fails for the right reason
2
2. GREEN  — write the minimum code to pass
3
3. REFACTOR — clean up, keep the test green

BDD with Gherkin and Robot Framework

BDD scenarios are written in Gherkin so non-programmers can read them:

1
Feature: Login
2
  Scenario: Reject a wrong password
3
    Given a registered user "ada" with password "s3cret"
4
    When the user signs in with password "wrong"
5
    Then the user sees "Invalid credentials"

Robot Framework is a keyword-driven, Python-based automation framework with its own tabular, plain-language syntax — widely used for BDD-style acceptance and RPA. It needs no programming to write the high-level test:

1
*** Test Cases ***
2
Reject A Wrong Password
3
    Given a registered user "ada" with password "s3cret"
4
    When the user signs in with password "wrong"
5
    Then the user sees "Invalid credentials"

Its ecosystem (SeleniumLibrary, RequestsLibrary, AppiumLibrary) makes it a strong choice for acceptance testing across web, API and mobile from one syntax.

Manual vs automated

	Manual	Automated
Best for	Exploratory, usability, one-off checks	Regression, repeated, high-volume
Cost profile	Cheap to start, expensive to repeat	Expensive to start, cheap to repeat
Evidence	Human judgement, screenshots	Deterministic pass/fail, artifacts

Most healthy teams do both: automate the regression suite, and reserve humans for exploratory and usability work where judgement is the point.