Testing theory & coverage

1 · The testing taxonomy

Here's an argument you've probably lost. A teammate says "we have 90% coverage, we're well tested." You have a nagging feeling that's not the whole story, but you can't name why — so the point goes unmade and a wiring bug ships. The problem wasn't your instinct; it was vocabulary. You didn't have the words to say "those are all unit tests — we have almost no integration coverage, which is exactly where this class of bug lives." A taxonomy isn't academic box-ticking; it's the language that lets you diagnose which kind of confidence a test suite actually buys you.

Think of testing like inspecting a new house. You can check a single fixture — does this one tap turn on? That's a unit test: one component in isolation. You can check that the tap, the pipe, and the water heater work together to deliver hot water — that's integration: two or more real parts wired up. You can walk the whole house as a buyer would, flushing toilets and flipping every switch — that's a system (end-to-end) test. And you can ask the entirely different question, "is this even the house I asked the builder for?" — that's acceptance. Each answers a real question, and none substitutes for another: a house with perfect taps can still have the wrong number of bedrooms.

That first axis — scope — is only half the map. The second, independent axis is how much the test can see. A black-box test knows only the interface: inputs go in, outputs come out, and it judges against the spec, never peeking at the source. A white-box test reads the code and is designed around its structure — this branch, that loop — which is how you deliberately chase coverage. Grey box sits between: you know some internals (a database schema, a cache) and use that partial knowledge to write sharper tests. The common mistake is collapsing these two axes into one — assuming "unit = white box, E2E = black box." They're genuinely independent: you can write a black-box unit test (call a pure function, assert its output, never read its body) or a white-box integration test. Naming both axes for any test you write is the skill this section trains, because the two answers together tell you what the test does — and does not — prove.

Before writing a test you should be able to name what kind it is on two independent axes. The first axis is scope — how much of the system it exercises. The second is knowledge of internals — whether the test sees the code or only the interface.

The orthogonal axis is how much the test knows about the implementation:

2 · The testing pyramid & the trophy

You've felt this one on a bad morning. You push a one-line fix, and the CI suite grinds for twenty-five minutes before going red on a test that has nothing to do with your change — it "flaked," someone says, so you click re-run and wait another twenty-five. When a suite is slow and unreliable, people stop trusting it: they merge on a re-run, they skip it locally, they eventually turn the flaky ones off. The suite that was supposed to protect you has become a tax you route around. The shape of your test suite — how many of each kind you have — is what decides whether it feels like a safety net or a toll booth.

The core physics is simple: the wider a test's scope, the more it costs and the flakier it gets. A unit test pokes one function in memory — it runs in a millisecond and either passes or fails for one crisp reason. An end-to-end test spins up the whole app, a real browser, a real database, the network — so it's a thousand times slower and can fail for a hundred unrelated reasons (a slow response, a timing race, a stale fixture). That cost gradient is why the classic testing pyramid is shaped the way it is: a broad base of many fast, stable unit tests, a narrower band of integration tests, and only a thin cap of expensive E2E tests. You want most of your confidence to come from the cheap, reliable layer.

So why does the competing testing trophy put its bulk at the integration layer instead? Because the pyramid quietly assumes your value lives in rich, branchy domain logic — the kind pure unit tests nail. Flip that assumption: a modern web service is often a thin skin of handlers over a database, with the real logic being how the pieces connect. Unit-test that in isolation and you mock the database away — leaving a hundred green units and a broken system, because every actual bug was in the wiring you stubbed out. There the trophy is right: test the handler against a real DB, and stand static analysis (types, lint) as a broad base underneath. The trophy isn't a rebuttal of the pyramid; it's the same cost/return reasoning applied to a different kind of code. The mistake to avoid is treating either shape as dogma — and the specific catastrophe to recognize is the ice-cream cone: the pyramid flipped upside down, mostly manual and E2E, almost no units, which gives you the slowest, flakiest, least-diagnostic suite possible.

How many of each level should you have? Two competing shapes answer this. The testing pyramid (Cohn) says: many fast unit tests at the base, fewer integration tests, very few slow E2E tests at the tip — because cost and flakiness rise as you go up.

The testing trophy (Dodds) argues that for I/O-heavy, well-typed applications the biggest return sits at the integration layer, with static analysis (types, lint) as a broad base. It is not a contradiction — it is a different cost/return profile:

3 · Equivalence partitioning & boundary-value analysis

The most expensive bugs hide behind the most reasonable-looking tests. You wrote a function that validates an age between 18 and 65. You tested it with 40 — it returned True, green tick, done. It shipped, and three weeks later a support ticket says a 65-year-old customer can't sign up. The test wasn't wrong; it was uninformative. Picking 40 told you nothing about the two places bugs actually live: the edges. This section is about choosing test inputs so that a small handful does the work of thousands — and so that the ones you pick are the ones that catch real bugs.

Start with the impossible problem: an age is an integer, so "test every input" means billions of cases. You obviously can't. But you don't need to, because most of those inputs are redundant — the function treats 40 exactly the way it treats 41, 42, and 39. That's the insight behind equivalence partitioning: carve the input space into classes where the code should behave identically, then test just one representative from each class. For the age check, the natural partitions are "too young" (below 18), "valid" (18–65), and "too old" (above 65) — three classes, so three well-chosen inputs cover the meaningful behaviours instead of billions of pointless ones. The representative is a stand-in: if 40 works, you trust that 41 does too, because they're in the same class.

But equivalence partitioning has a blind spot, and boundary-value analysis (BVA) exists to fill it. Bugs don't cluster in the calm middle of a class — they cluster at the edges, where one range meets the next, because that's where a programmer typed < when they meant <=, or wrote 18 where the spec said 17. Off-by-one errors are the single most common logic mistake in the industry, and they live exactly on the boundary. So BVA says: for a range [lo, hi], don't just test a middle value — test the six points that straddle both edges: lo-1, lo, lo+1 and hi-1, hi, hi+1. For 18–65 that's 17, 18, 19, 64, 65, 66 — the just-outside, just-on, and just-inside points at each end. This is where the earlier "test with 40" fails and BVA wins: 40 sits deep in the valid class and can never reveal a mishandled boundary, whereas testing 65 directly interrogates the <= vs < decision. The common trap is testing only on the boundary (just 18 and 65) and skipping the neighbours — but a boundary bug can push the edge one step either way, so you need the point just outside and just inside to pin it down. Equivalence partitioning shrinks the input space; BVA aims what's left at the edges where bugs actually breed. The lab below turns exactly this into an off-by-one that a happy-path test sails right past.

You cannot test every input. Equivalence partitioning divides the input space into classes where the program should behave the same, so one representative per class suffices. Boundary-value analysis (BVA) then adds the fact that bugs cluster at the edges of those classes — so for a range [lo, hi] you test lo-1, lo, lo+1, hi-1, hi, hi+1. The lab finds a real off-by-one that a happy-path test misses entirely.

bva.py# The classic off-by-one: "valid age is 18..65 inclusive". A buggy check uses
# `< 65` instead of `<= 65`, silently rejecting the upper boundary (65).
def eligible_buggy(age):
    return 18 <= age < 65            # BUG: excludes 65

def eligible_fixed(age):
    return 18 <= age <= 65           # correct: 65 is valid

# Boundary-Value Analysis test set: for a range [lo, hi] test
# lo-1, lo, lo+1, hi-1, hi, hi+1  (the 6 points where bugs cluster).
def bva_points(lo, hi):
    return [lo - 1, lo, lo + 1, hi - 1, hi, hi + 1]

points = bva_points(18, 65)          # [17, 18, 19, 64, 65, 66]
expected = [False, True, True, True, True, False]

# A naive "happy-path" suite only tries a middle value and both pass:
print("happy-path only  :", eligible_buggy(40) == True, eligible_fixed(40) == True)

# BVA catches the bug precisely at the upper boundary (65):
buggy = [eligible_buggy(a) for a in points]
fixed = [eligible_fixed(a) for a in points]
print("boundary points  :", points)
print("buggy  results   :", buggy)
print("fixed  results   :", fixed)
print("first mismatch   :", next(p for p, b, e in zip(points, buggy, expected) if b != e))

happy-path only  : True True
boundary points  : [17, 18, 19, 64, 65, 66]
buggy  results   : [False, True, True, True, False, False]
fixed  results   : [False, True, True, True, True, False]
first mismatch   : 65

The happy-path line passes for both the buggy and fixed versions — a middle value like 40 tells you nothing. Only the boundary point 65 exposes that < 65 wrongly rejects the inclusive upper bound. This is the single highest-yield test-design technique for exams and real bugs alike.

4 · Decision-table testing

Here's the bug that gets through the most careful reviewer. A login rule says "allow if the password is valid, the account is active, and it isn't locked." You test a valid login — works. You test a wrong password — denied. You feel thorough. Then a locked account with a valid password somehow gets in, because nobody tested that particular combination. It's not that the logic was hard; it's that three yes/no conditions produce more combinations than a human tests by intuition, and the one you skip is always the one that bites. Decision-table testing is the discipline that makes skipping a combination impossible.

The trap with combinations is that they grow faster than your patience. One condition has 2 cases. Two conditions have 4. Three have 8. The formula is 2ⁿ for n boolean conditions — exponential — and the human brain quietly gives up somewhere around four, testing the "obvious" combinations and assuming the rest. A decision table refuses that shortcut: you write one row per rule, listing every combination of conditions down the left and its expected action on the right, so the table itself guarantees completeness. If there are eight combinations, there are eight rows; a missing row is visible at a glance. Crucially this is a black-box technique — you build the table from the specification, from what the rule is supposed to do, not from reading the code. That's the whole point: it catches the case the code forgot to handle, which no amount of white-box coverage of the existing code can ever reveal.

Real specs, of course, aren't always eight tidy rows — a policy might have six conditions (64 rows) with many combinations that don't matter. That's where don't-care entries earn their keep: once you notice that "if the password is invalid, nothing else matters — it's always DENY," you can collapse all those rows into one, marking the irrelevant conditions with a dash. But the discipline is to derive the full table first and collapse second, so every collapse is a justified decision rather than a combination you simply never thought of. Skip straight to the collapsed table and you're back to guessing which conditions matter — which is exactly the intuition the technique was meant to replace. The lab enumerates all 2³ = 8 rules for the login policy so you can see the one true ALLOW row surrounded by seven DENYs.

When behaviour depends on a combination of conditions, a decision table enumerates every rule (2ⁿ for n boolean conditions) and its expected action, so you cannot forget a combination. It is a black-box technique: it comes from the spec, not the code.

decision_table.py# Decision-table testing: enumerate rules over conditions, derive expected action.
# Login policy: allow only if (valid_password AND account_active AND NOT locked).
from itertools import product

def decide(valid_pw, active, locked):
    return "ALLOW" if (valid_pw and active and not locked) else "DENY"

conditions = ["valid_pw", "active", "locked"]
print(f"{'valid_pw':>9} {'active':>7} {'locked':>7} | action")
allow_rows = 0
for valid_pw, active, locked in product([True, False], repeat=3):
    action = decide(valid_pw, active, locked)
    allow_rows += action == "ALLOW"
    print(f"{str(valid_pw):>9} {str(active):>7} {str(locked):>7} | {action}")
print("rules:", 2**len(conditions), "| ALLOW rules:", allow_rows)

 valid_pw  active  locked | action
     True    True    True | DENY
     True    True   False | ALLOW
     True   False    True | DENY
     True   False   False | DENY
    False    True    True | DENY
    False    True   False | DENY
    False   False    True | DENY
    False   False   False | DENY
rules: 8 | ALLOW rules: 1

Three conditions give 2³ = 8 rules; exactly one yields ALLOW. In practice you collapse rules whose outcome is independent of a condition (don't-care entries) to shrink the table — but you derive it in full first so the collapse is justified.

5 · State-transition testing

You know this bug from your own bank app. You tap "Pay" twice because the first tap seemed to hang — and get charged twice. Or you hit the browser Back button after checking out and the app cheerfully lets you re-submit the order. The code handled the intended sequence perfectly; what it never considered was the same action arriving in a state where it shouldn't be allowed. Stateful bugs aren't about a single wrong output — they're about the system doing the right thing in the wrong moment. State-transition testing is how you hunt them systematically instead of stumbling on them in production.

The mental model that unlocks this is to stop thinking of your object as "code with variables" and start seeing it as a finite-state machine: a small set of named states, and events that move it from one state to another. A subway turnstile is the textbook example because it's so concrete: it's either LOCKED or UNLOCKED, and two events act on it — inserting a coin and giving it a push. The revealing part is that the same event does different things in different states: a push while UNLOCKED lets you through and re-locks the gate, but a push while LOCKED must be refused. Once you draw the machine — states as boxes, events as arrows — the test cases stop being a matter of imagination and become a matter of enumeration: one test per arrow you drew.

And here's the arrow juniors always forget. It's easy to test the legal path — coin, then push, then through — because that's the story you had in mind when you wrote the code. The bugs live in the illegal transitions: the events that arrive in a state where they make no sense. Pushing a locked turnstile, inserting a second coin, paying an already-paid invoice, cancelling a shipped order. The rule that separates robust code from fragile code is that an illegal event must be explicitly rejected — not silently swallowed. Silent swallowing is the trap: the code doesn't crash, so it looks fine, but it has quietly entered a nonsensical state (charged twice, double-shipped) that surfaces as a data-corruption ticket weeks later. The systematic guard is a transition table with one row for every (state, event) pair — including the illegal pairs, each with its expected rejection — so that no arrow, legal or illegal, goes untested. The lab below encodes exactly the turnstile machine and makes a point of asserting that a push while LOCKED returns BLOCKED rather than passing through.

Stateful code is a finite-state machine: the same event does different things in different states. State-transition testing covers each legal transition and each illegal event (which must be rejected, not silently swallowed). The turnstile is the canonical example.

state_transition.pyimport unittest

# State-transition testing: a turnstile FSM. States: LOCKED, UNLOCKED.
# Events: coin, push. Illegal transitions must be rejected, not silently ignored.
class Turnstile:
    def __init__(self):
        self.state = "LOCKED"
    def coin(self):
        self.state = "UNLOCKED"        # coin always unlocks
    def push(self):
        if self.state == "UNLOCKED":
            self.state = "LOCKED"      # a valid push passes through, re-locks
            return "PASS"
        return "BLOCKED"               # pushing a locked gate is blocked

class TestTurnstile(unittest.TestCase):
    def setUp(self): self.t = Turnstile()
    def test_happy_path(self):
        self.t.coin()
        self.assertEqual(self.t.push(), "PASS")
        self.assertEqual(self.t.state, "LOCKED")
    def test_push_while_locked_is_blocked(self):
        self.assertEqual(self.t.push(), "BLOCKED")   # illegal event handled
        self.assertEqual(self.t.state, "LOCKED")
    def test_two_coins_still_one_pass(self):
        self.t.coin(); self.t.coin()                 # coin is idempotent-ish
        self.assertEqual(self.t.push(), "PASS")

if __name__ == "__main__":
    unittest.main(verbosity=2)

test_happy_path (__main__.TestTurnstile.test_happy_path) ... ok
test_push_while_locked_is_blocked (__main__.TestTurnstile.test_push_while_locked_is_blocked) ... ok
test_two_coins_still_one_pass (__main__.TestTurnstile.test_two_coins_still_one_pass) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.000s

OK

test_push_while_locked_is_blocked is the one juniors forget: it asserts the illegal event (push while LOCKED) is handled gracefully. A transition table with one row per (state, event) pair is the systematic way to guarantee none is missed.

6 · Coverage theory: statement → branch → path → MC-DC

"We're at 100% coverage" is one of the most reassuring lies in software. A manager sees the green badge and signs off; a bug ships in a code path that the coverage report swore was tested. The report wasn't lying about what it measured — it was measuring the wrong thing, and nobody knew the difference between the kinds of coverage. This section is about that difference, because "coverage" is not one number: it's a ladder of increasingly strict questions, and knowing which rung you're standing on is the difference between real confidence and a green badge that means almost nothing.

The weakest rung is statement coverage: did every line of code run at least once? It sounds thorough until you meet an if with no else. Consider if user.is_admin: grant_access(). A single test with an admin user runs both lines — 100% statement coverage — while never once checking what happens to a non-admin. The dangerous branch (the one that should deny access) was never taken, yet the report is a perfect green. That's why the next rung up, branch coverage (also called decision coverage), asks the stronger question: did every decision go both True and False? Branch coverage subsumes statement coverage — take every branch and you've necessarily run every line — which is why it's the target most CI pipelines actually enforce. The relationship matters: the ladder is nested, each rung guaranteeing the ones below it.

Above branch coverage the questions get subtler and aimed at compound decisions like if x > 0 and y > 0. Condition coverage asks that each atomic condition (x>0, y>0) be seen both true and false — but, surprisingly, that alone doesn't guarantee branch coverage, because short-circuit evaluation can flip individual conditions without ever flipping the overall decision. MC-DC (Modified Condition/Decision Coverage) closes that gap with a demanding rule: every condition must be shown to independently flip the final decision, holding the others fixed. It's expensive enough that it's mandated only where lives are at stake — the DO-178C avionics standard. At the top sits path coverage — every possible route through the code — which is complete but usually infeasible, since loops and branches multiply paths exponentially. The one lesson to carry out of the whole ladder is the trap the lab makes concrete: coverage is necessary but not sufficient. It proves a line ran; it never proves you asserted the right thing — a test with no assertion at all still counts as full coverage — and it's blind to code you forgot to write. Chase it to find untested gaps, never to certify correctness; measuring the strength of your assertions is a different tool (mutation testing, in TQ7).

Coverage is a white-box measure of what your tests execute. The hierarchy, from weakest to strongest:

The lab makes the key point concrete: a suite can hit every statement (100% statement coverage) yet leave a branch outcome untaken — so 100% statement coverage is not correctness.

coverage_theory.pyimport unittest

# The function under test. Two conditions in one `if` (a compound decision),
# plus a branch that returns early.
def classify(x, y):
    if x > 0 and y > 0:      # decision D1 with conditions C1:(x>0) C2:(y>0)
        return "both-pos"
    if x == y:               # decision D2
        return "equal"
    return "other"

# --- Coverage models (computed by hand so you see exactly what each counts) ---
# Statements: the 4 executable lines inside classify.
# Branches:   each decision's True AND False outcome  -> 4 branch outcomes.
# Conditions: each atomic condition True AND False     -> C1,C2 each way + D2.
STATEMENTS = {"if1", "ret_both", "if2", "ret_equal_or_other"}
BRANCHES   = {"D1-T", "D1-F", "D2-T", "D2-F"}

def run(tests):
    stmt, brch = set(), set()
    for x, y in tests:
        stmt.add("if1")
        if x > 0 and y > 0:
            stmt.add("ret_both"); brch.add("D1-T")
        else:
            brch.add("D1-F")
            stmt.add("if2")
            if x == y:
                stmt.add("ret_equal_or_other"); brch.add("D2-T")
            else:
                stmt.add("ret_equal_or_other"); brch.add("D2-F")
    return stmt, brch

def pct(got, whole):
    return f"{len(got & whole)}/{len(whole)} = {100*len(got & whole)//len(whole)}%"

# Suite A: two tests. Reaches every *statement* -> 100% statement coverage...
suite_a = [(1, 1), (-2, -2)]
sa_stmt, sa_brch = run(suite_a)
print("suite A statement:", pct(sa_stmt, STATEMENTS))
print("suite A branch   :", pct(sa_brch, BRANCHES), "-> misses", sorted(BRANCHES - sa_brch))

# ...yet it never takes the False branch of D2, so a bug there hides.
# Suite B adds a non-equal negative case to cover every branch outcome.
suite_b = [(1, 1), (-2, -2), (-2, -3)]
sb_stmt, sb_brch = run(suite_b)
print("suite B branch   :", pct(sb_brch, BRANCHES))
print("100% statement != correct:", len(sa_stmt) == len(STATEMENTS), "yet branch only", pct(sa_brch, BRANCHES))

suite A statement: 4/4 = 100%
suite A branch   : 3/4 = 75% -> misses ['D2-F']
suite B branch   : 4/4 = 100%
100% statement != correct: True yet branch only 3/4 = 75%

Suite A executes all 4 statements — a green 100% on a statement-coverage report — but never takes the False branch of D2 (the x != y case), so it sits at 75% branch coverage. A bug in that untaken path is invisible until Suite B adds the non-equal negative case. In a real project you would get these numbers from coverage.py / pytest --cov --cov-branch; MC-DC needs a dedicated tool.

Knowledge check

import unittest

def letter_grade(score):
    if not 0 <= score <= 100:
        raise ValueError("score must be 0-100")
    if score >= 90: return "A"
    if score >= 80: return "B"
    if score >= 70: return "C"
    if score >= 60: return "D"
    return "F"

class TestGrade(unittest.TestCase):
    def test_classes(self):
        for score, grade in [(95,"A"),(85,"B"),(75,"C"),(65,"D"),(30,"F")]:
            self.assertEqual(letter_grade(score), grade)
    def test_invalid_class(self):
        with self.assertRaises(ValueError): letter_grade(150)

if __name__ == "__main__":
    unittest.main(verbosity=2)   # 2 tests OK

import unittest

def bva_points(lo, hi): return [lo-1, lo, lo+1, hi-1, hi, hi+1]
def in_range_buggy(x): return 1 <= x < 100     # BUG
def in_range_ok(x):    return 1 <= x <= 100

class TestBVA(unittest.TestCase):
    def test_boundary_mismatch(self):
        pts = bva_points(1, 100)                  # [0,1,2,99,100,101]
        diffs = [p for p in pts if in_range_buggy(p) != in_range_ok(p)]
        self.assertEqual(diffs, [100])           # only 100 differs

if __name__ == "__main__":
    unittest.main(verbosity=2)   # 1 test OK

import unittest
from itertools import product

def free_shipping(member, big_cart, coupon):
    return member and (big_cart or coupon)

class TestDecisionTable(unittest.TestCase):
    def test_free_rules(self):
        rules = list(product([True, False], repeat=3))
        free = [r for r in rules if free_shipping(*r)]
        # member=T and (big_cart or coupon): (T,T,T),(T,T,F),(T,F,T) -> 3
        self.assertEqual(len(free), 3)
        self.assertEqual(len(rules), 8)

if __name__ == "__main__":
    unittest.main(verbosity=2)   # 1 test OK

import unittest

class Player:
    def __init__(self): self.state = "STOPPED"
    def play(self):  self.state = "PLAYING"
    def pause(self):
        if self.state != "PLAYING":
            raise RuntimeError("can only pause while playing")
        self.state = "PAUSED"
    def stop(self):  self.state = "STOPPED"

class TestPlayer(unittest.TestCase):
    def setUp(self): self.p = Player()
    def test_play_then_pause(self):
        self.p.play(); self.p.pause()
        self.assertEqual(self.p.state, "PAUSED")
    def test_stop_from_playing(self):
        self.p.play(); self.p.stop()
        self.assertEqual(self.p.state, "STOPPED")
    def test_illegal_pause_when_stopped(self):
        with self.assertRaises(RuntimeError): self.p.pause()
        self.assertEqual(self.p.state, "STOPPED")   # unchanged

if __name__ == "__main__":
    unittest.main(verbosity=2)   # 3 tests OK

def run(tests):
    stmt, brch = set(), set()
    for n in tests:
        stmt.add("enter")
        if n < 0:
            stmt.add("neg"); brch.add("T")
        else:
            brch.add("F")
        stmt.add("exit")
    return stmt, brch

STMT = {"enter", "neg", "exit"}; BR = {"T", "F"}
s1, b1 = run([-1])            # only the negative case
print("suite1 stmt", f"{len(s1&STMT)}/{len(STMT)}", "branch", f"{len(b1&BR)}/{len(BR)}")
s2, b2 = run([-1, 5])         # add a non-negative case
print("suite2 branch", f"{len(b2&BR)}/{len(BR)}")
# suite1 stmt 3/3 branch 1/2  ->  suite2 branch 2/2

FLOORS = {"safety": 100, "core": 85, "peripheral": 60}
MCDC_REQUIRED = {"safety"}

def check(modules):
    problems = []
    for m in modules:
        floor = FLOORS[m["tier"]]
        if m["branch_cov"] < floor:
            problems.append((m["name"], m["tier"], floor - m["branch_cov"]))
        if m["tier"] in MCDC_REQUIRED and not m.get("mcdc"):
            problems.append((m["name"], "MC-DC missing", 0))
    return problems

mods = [
    {"name": "auth",   "tier": "safety",     "branch_cov": 96, "mcdc": False},
    {"name": "pricing","tier": "core",       "branch_cov": 88, "mcdc": False},
    {"name": "logfmt", "tier": "peripheral", "branch_cov": 55, "mcdc": False},
]
for p in check(mods): print(p)
# ('auth', 'safety', 4)
# ('auth', 'MC-DC missing', 0)
# ('logfmt', 'peripheral', 5)