Coverage আর complexity — statement, branch coverage, cyclomatic complexity আর mutation testing

১ · Coverage কী মাপে — আর কী মাপে না

পর্ব ৪৫-এ (Testing-এর মৌলিক) দেখেছেন, white-box testing-এ test নকশা হয় কোডের ভেতরের গঠন দেখে, আর black-box-এ শুধু বাইরের আচরণ দেখে। পর্ব ৪৭-এ (Test case নকশা) black-box কৌশল — equivalence partitioning, boundary value আর decision table. এই পর্ব white-box দিকের মাপকাঠি: আপনার test কোডের কোন অংশ ছুঁয়েছে, কোন অংশ ছোঁয়নি, আর কোডটি নিজে কতটা জটিল।

Coverage-কে বলা হয় test adequacy criterion — test suite “যথেষ্ট” কি না তার একটি মাপকাঠি। প্রতিটি মাপকাঠি একটি প্রশ্ন: “প্রতিটি লাইন অন্তত একবার চলেছে?” “প্রতিটি if-এর দুই দিকই নেওয়া হয়েছে?” “প্রতিটি শর্ত আলাদাভাবে ফলাফল বদলাতে পেরেছে?” প্রশ্ন যত কড়া, পূরণ করতে test তত বেশি লাগে। Coverage-এর সাধারণ সূত্র:

২ · Control-flow graph — কোড থেকে ছবি

সব white-box মাপের ভিত্তি একটি ছবি: control-flow graph (CFG). রেলের রুট-ম্যাপ যেমন দেখায় কোন স্টেশন থেকে কোন স্টেশনে যাওয়া যায়, CFG তেমনি দেখায় কোডের কোন অংশের পরে কোন অংশ চলতে পারে। পর্ব ২৩ (Requirement modeling) আর পর্ব ৩০-এর (UML behaviour diagram) activity diagram-এ পথ গোনা দেখেছেন; CFG একই ধারণা, কিন্তু কোডের স্তরে আর কড়া নিয়মে।

• Node: একটি basic block — পরপর চলা statement-এর দল, যাতে ঢোকার পথ একটি (প্রথম লাইন) আর বের হওয়ার পথ একটি (শেষ লাইন)। মাঝখানে কোনো লাফ নেই। তাই let a = 0; let b = 1; দুই লাইন হলেও একটি node.
• Edge: তীর — একটি block শেষ হলে নিয়ন্ত্রণ কোন block-এ যেতে পারে।
• Decision node (predicate node): যে node থেকে দুই বা ততোধিক তীর বের হয় — if, while, for-এর শর্ত, switch. দুই-মুখী হলে তীরে T (true) আর F (false) লেখা হয়।
• Entry আর exit: function-এর শুরুর node আর শেষের node. ভালোভাবে গঠিত function-এ একটি করে।

প্রতিটি গঠনের ছবি নির্দিষ্ট: if (else ছাড়া) একটি decision, এক দিক body হয়ে নিচে মেলে, অন্য দিক সরাসরি নিচে; if/else-এ দুই দিক দুই body পেরিয়ে মেলে; while-এ শর্তের node থেকে T দিক body-তে, body শেষে একটি back edge আবার শর্তে, আর F দিক loop-এর বাইরে। for (init; cond; step) আসলে init + while (cond) { body; step }. নিচের কাল্পনিক function-টি একটি পরীক্ষার ফলের তালিকা থেকে পাস আর পূর্ণ নম্বর পাওয়া শিক্ষার্থী গোনে। Stepper-এ বাঁয়ে কোডের লাইন, ডানে CFG ধাপে ধাপে তৈরি হচ্ছে:

1function summary(marks) {2  let pass = 0, full = 0, i = 0;3  while (i < marks.length) {4    if (marks[i] >= 40) {5      pass++;6    }7    if (marks[i] === 100) {8      full++;9    }10    i++;11  }12  return { pass, full };13}

এবার একই graph-এর পূর্ণ ছবি, region-সহ। Graph-কে কাগজে এমনভাবে আঁকা যায় যাতে কোনো তীর অন্যটিকে কাটে না (planar graph); তখন তীরগুলো কাগজকে কয়েকটি বদ্ধ এলাকায় ভাগ করে, আর বাইরের অসীম এলাকাটিও একটি region হিসেবে গোনা হয়।

৩ · Statement আর branch coverage — হিসাব আর পার্থক্য

প্রথম দুটি মাপকাঠি সবচেয়ে প্রচলিত, আর বেশিরভাগ tool এগুলোই দেখায়।

পার্থক্য সবচেয়ে বেশি দেখা যায় else ছাড়া if-এ। নিচে একটি কাল্পনিক ফল-নির্ধারণ function: বোনাস থাকলে ৫ নম্বর যোগ, ১০০-এর বেশি হলে ১০০-তে আটকানো, তারপর ৪০ বা তার বেশি হলে PASS. প্রোগ্রামটি Python-এর sys.settrace দিয়ে প্রতিটি চলা লাইন রেকর্ড করে — coverage tool ভেতরে এমনই একটি hook ব্যবহার করে। Branch বোঝা হয় পরপর দুটি চলা লাইনের জোড়া (arc) দেখে: decision লাইনের পরে body-র লাইন চললে T, অন্য লাইনে লাফ দিলে F. তিনটি test suite মাপা হচ্ছে:

import sys
SRC = '''def grade(marks, bonus):
    if bonus:
        marks = marks + 5
    if marks > 100:
        marks = 100
    if marks >= 40:
        return "PASS"
    return "FAIL"
'''
ns = {}
exec(compile(SRC, "grade.py", "exec"), ns)
STMTS = {2, 3, 4, 5, 6, 7, 8}                 # executable lines of the body
BRANCH = {2: (3, 4), 4: (5, 6), 6: (7, 8)}    # decision line: (True-next, False-next)
def measure(tests):
    lines, arcs, prev = set(), set(), [None]
    def tracer(frame, event, arg):
        if frame.f_code.co_name != "grade": return None
        if event == "call": prev[0] = None
        if event == "line":
            lines.add(frame.f_lineno)
            if prev[0]: arcs.add((prev[0], frame.f_lineno))
            prev[0] = frame.f_lineno
        return tracer
    sys.settrace(tracer)
    for m, b in tests: ns["grade"](m, b)
    sys.settrace(None)
    taken = {(d, o) for d, tf in BRANCH.items() for o, nxt in zip("TF", tf) if (d, nxt) in arcs}
    missed = sorted({(d, o) for d in BRANCH for o in "TF"} - taken)
    s, b = len(lines & STMTS), len(taken)
    print(f"tests={tests}\n  lines run {sorted(lines & STMTS)}  missed {sorted(STMTS - lines)}")
    print(f"  missed branches {missed}\n  statement {s}/7 = {100*s/7:.1f}%   branch {b}/6 = {100*b/6:.1f}%")

for suite in ([(50, True)], [(98, True), (30, True)], [(98, True), (30, False)]):
    measure(suite)

tests=[(50, True)]
  lines run [2, 3, 4, 6, 7]  missed [5, 8]
  missed branches [(2, 'F'), (4, 'T'), (6, 'F')]
  statement 5/7 = 71.4%   branch 3/6 = 50.0%
tests=[(98, True), (30, True)]
  lines run [2, 3, 4, 5, 6, 7, 8]  missed []
  missed branches [(2, 'F')]
  statement 7/7 = 100.0%   branch 5/6 = 83.3%
tests=[(98, True), (30, False)]
  lines run [2, 3, 4, 5, 6, 7, 8]  missed []
  missed branches []
  statement 7/7 = 100.0%   branch 6/6 = 100.0%

৪ · শর্তের স্তরে — condition, condition/decision, MC/DC আর multiple-condition

একটি decision (if-এর পুরো শর্ত) কয়েকটি condition-এর তৈরি হতে পারে — &&, || দিয়ে জোড়া, যেখানে প্রতিটি condition নিজে আর ভাঙা যায় না (যেমন marks >= 40, absent). Branch coverage শুধু পুরো decision-এর ফল দেখে; ভেতরের কোন condition কী করল, দেখে না। তাই শর্তের স্তরে চারটি মাপকাঠি, দুর্বল থেকে কড়া:

প্রথম সারির ফাঁদটি পরীক্ষায় খুব আসে: condition coverage, decision coverage-কে subsume করে না। (T,F) আর (F,T)-এ a আর b দুটিই দুই মান পেয়েছে, অথচ a && b দুবারই মিথ্যা — if-এর body একবারও চলেনি, তাই statement coverage-ও পূরণ হয়নি। এজন্যই C/DC-তে দুটিকে একসাথে চাওয়া হয়।

MC/DC — প্রতিটি শর্তের নিজস্ব প্রভাব

MC/DC-র মূল কথা হলো independence pair: দুটি test, যেখানে শুধু একটি condition আলাদা, আর decision-এর ফলও আলাদা। এমন জোড়া থাকলে প্রমাণ হয় ওই condition-টি সত্যিই ফলাফলে প্রভাব রাখে — কোডে সেটি থাকা অর্থহীন নয়, আর ভুল লিখলে কোনো না কোনো test ধরবে। নিচের প্রোগ্রাম (a and b) or c-এর আটটি সমন্বয় তৈরি করে, প্রতিটি condition-এর independence pair খোঁজে, তারপর সবচেয়ে ছোট test set বের করে যেখানে তিনটি condition-এরই অন্তত একটি জোড়া আছে:

from itertools import product, combinations

def D(a, b, c):                       # the decision under test
    return (a and b) or c

rows = list(product([0, 1], repeat=3))          # all 8 combinations (a, b, c)
out = {r: int(bool(D(*r))) for r in rows}
for i, r in enumerate(rows, 1):
    print(f"T{i}: a={r[0]} b={r[1]} c={r[2]} -> {out[r]}")

# independence pairs: only condition k differs AND the outcome differs
pairs = {k: [] for k in range(3)}
for r, s in combinations(rows, 2):
    diff = [k for k in range(3) if r[k] != s[k]]
    if len(diff) == 1 and out[r] != out[s]:
        pairs[diff[0]].append((rows.index(r) + 1, rows.index(s) + 1))
for k, name in enumerate("abc"):
    print(f"{name} independence pairs: {pairs[k]}")

def is_mcdc(tests):                    # every condition shown by a pair inside the set
    return all(any(p in tests and q in tests for p, q in pairs[k]) for k in range(3))

for size in range(1, 9):
    found = [t for t in combinations(range(1, 9), size) if is_mcdc(set(t))]
    if found:
        print(f"smallest MC/DC set size = {size} (n+1 = {3 + 1}); all of them: {found}")
        break
print(f"multiple-condition coverage needs 2^3 = {len(rows)} tests")

T1: a=0 b=0 c=0 -> 0
T2: a=0 b=0 c=1 -> 1
T3: a=0 b=1 c=0 -> 0
T4: a=0 b=1 c=1 -> 1
T5: a=1 b=0 c=0 -> 0
T6: a=1 b=0 c=1 -> 1
T7: a=1 b=1 c=0 -> 1
T8: a=1 b=1 c=1 -> 1
a independence pairs: [(3, 7)]
b independence pairs: [(5, 7)]
c independence pairs: [(1, 2), (3, 4), (5, 6)]
smallest MC/DC set size = 4 (n+1 = 4); all of them: [(3, 4, 5, 7), (3, 5, 6, 7)]
multiple-condition coverage needs 2^3 = 8 tests

৫ · Path coverage আর subsumption-এর সিঁড়ি

Path coverage সবচেয়ে কড়া structural মাপকাঠি: entry থেকে exit পর্যন্ত প্রতিটি সম্ভাব্য পথ অন্তত একবার। সমস্যা দুটি। প্রথমত, বিস্ফোরণ: পরপর ১০টি স্বাধীন if থাকলে পথ 2¹⁰ = ১০২৪টি; আর loop থাকলে — summary-এর loop যতবার খুশি ঘুরতে পারে, প্রতিটি ঘূর্ণনে ৪ রকম ভেতরের পথ — ঘূর্ণন সীমাহীন হলে পথও অসীম। দ্বিতীয়ত, infeasible path: graph-এ আঁকা কিছু পথ বাস্তবে কোনো ইনপুটেই চলে না, কারণ শর্তগুলো পরস্পর-নির্ভর (অনুশীলন ২-এ একটি দেখবেন)। তাই বাস্তবে path coverage-এর বদলে সীমিত রূপ ব্যবহৃত হয়: loop শূন্য, এক আর বহুবার (boundary interior), অথবা পরের অংশের basis path.

সব মাপকাঠি একসাথে, subsumption-এর তীর দিয়ে। তীর A → B মানে A পূরণ হলে B-ও পূরণ:

এক নজরে, পরীক্ষার জন্য একটি ছোট নিয়ম: “কোন মাপকাঠিতে সবচেয়ে কম কয়টি test লাগে” প্রশ্নে প্রথমে CFG আঁকুন, তারপর প্রতিটি লক্ষ্য (node, edge, শর্তের মান, জোড়া) ঢাকতে একটি test কতগুলো লক্ষ্য একসাথে ছুঁতে পারে ভাবুন — আর পরস্পর-নির্ভর শর্তের কারণে কোনো সমন্বয় অসম্ভব কি না যাচাই করুন।

৬ · Cyclomatic complexity — এক graph, তিন হিসাব

১৯৭৬ সালে Thomas J. McCabe IEEE Transactions on Software Engineering-এ “A Complexity Measure” প্রবন্ধে graph তত্ত্ব থেকে একটি সংখ্যা আনেন: cyclomatic complexity, V(G). অর্থ: CFG-তে কতগুলো linearly independent path আছে — এমন পথের সবচেয়ে বড় দল, যার কোনোটি বাকিগুলোর edge জোড়াতালি দিয়ে বানানো যায় না। একই সংখ্যা তিনভাবে বের হয়:

• E − N + 2P সব সময় খাটে। কয়েকটি function একসাথে (P = ৩) হলে প্রতিটির V(G) যোগ করলেই মোট।
• Decision + ১ খাটে single-entry, single-exit function-এ যেখানে প্রতিটি decision দুই-মুখী। switch-এ k-টি শাখা থাকলে সেটি k − ১টি দুই-মুখী decision-এর সমান।
• Region-এর সংখ্যা খাটে graph planar হলে (কোনো তীর অন্যটিকে না কেটে আঁকা যায়); বাইরের এলাকাসহ গুনতে হয়। এটি Euler-এর সূত্র (N − E + F = ২) থেকে আসে।

নিচের stepper-এ ছবি ৫০.১-এর graph-এ তিনটি হিসাব, তারপর basis set-এর চারটি পথ:

নিচের JavaScript একই graph হাতে লিখে (node → পরের node-এর তালিকা) তিনটি হিসাব করে, baseline পদ্ধতিতে basis set বানায়, আর প্রমাণ করে যে পথগুলো সত্যিই স্বাধীন: প্রতিটি পথকে ১০টি edge-এর গোনা দিয়ে একটি vector বানিয়ে তাদের rank (Gaussian elimination) বের করে।

// CFG of summary(marks), drawn by hand: node -> [trueNext, falseNext] or [next]
const G = { 1: [2], 2: [3, 8], 3: [4, 5], 4: [5], 5: [6, 7], 6: [7], 7: [2], 8: [] };
const N = Object.keys(G).length, P = 1;        // one function = one connected part
const E = Object.values(G).reduce((s, out) => s + out.length, 0);
const decisions = Object.values(G).filter(out => out.length === 2).length;
// faces of the planar drawing (Figure 50.2), listed by hand: 3 inside + outer
const faces = ["R1: 2-3-5-7-2", "R2: 3-4-5-3", "R3: 5-6-7-5", "R4: outer"];
console.log(`N=${N} E=${E} P=${P} decisions=${decisions}`);
console.log(`(1) E - N + 2P   = ${E - N + 2 * P}`);
console.log(`(2) decisions + 1 = ${decisions + 1}`);
console.log(`(3) regions       = ${faces.length}  (Euler check E-N+2 = ${E - N + 2})`);
// Basis set, McCabe's baseline method: flip one decision at a time.
const base = { 2: 0, 3: 0, 5: 1 };             // baseline: enter loop, pass, not full
function walk(flip) {
  const path = [1], seen = new Set();          // loop runs at most once per path
  for (let n = 1; G[n].length; path.push(n)) {
    const k = G[n].length < 2 ? 0 : seen.has(n) ? 1 : n === flip ? 1 - base[n] : base[n];
    seen.add(n); n = G[n][k];
  }
  return path;
}
const basis = [walk(null), ...Object.keys(base).map(d => walk(Number(d)))];
const edgeVec = p => Object.entries(G).flatMap(([a, out]) =>
  out.map(b => p.slice(1).filter((x, i) => p[i] == a && x == b).length));
function rank(m) {                              // Gaussian elimination
  let r = 0;
  for (let c = 0; c < m[0].length && r < m.length; c++) {
    const p = m.findIndex((row, i) => i >= r && row[c] !== 0); if (p < 0) continue;
    [m[r], m[p]] = [m[p], m[r]];
    m = m.map((row, i) => i === r ? row : row.map((v, j) => v - row[c] / m[r][c] * m[r][j])); r++;
  }
  return r;
}
basis.forEach((p, i) => console.log(`basis P${i + 1}: ${p.join("-")}`));
console.log(`rank of edge vectors = ${rank(basis.map(edgeVec))}`);

N=8 E=10 P=1 decisions=3
(1) E - N + 2P   = 4
(2) decisions + 1 = 4
(3) regions       = 4  (Euler check E-N+2 = 4)
basis P1: 1-2-3-4-5-7-2-8
basis P2: 1-2-8
basis P3: 1-2-3-5-7-2-8
basis P4: 1-2-3-4-5-6-7-2-8
rank of edge vectors = 4

Basis path testing — ধাপগুলো

1. Code থেকে CFG আঁকা (যুক্ত শর্ত ভেঙে, যদি condition-স্তরে চান)।
2. V(G) হিসাব — অন্তত দুই পদ্ধতিতে, মিলিয়ে নিতে।
3. V(G)টি স্বাধীন পথের একটি basis set বের করা (baseline + একটি করে decision উল্টানো)।
4. প্রতিটি পথ চালাবে এমন ইনপুট বেছে নেওয়া; infeasible হলে পথ বদলানো।
5. প্রতিটি ইনপুটের প্রত্যাশিত ফল specification থেকে লেখা — কোড থেকে নয়।
6. Test চালিয়ে আসল ফল প্রত্যাশার সাথে মেলানো।

McCabe-এর structured testing-এর দাবি: basis set চালানো test suite branch coverage নিশ্চিত করে, আর সাধারণত branch coverage-এর ন্যূনতম suite-এর চেয়ে বেশি পথ-সমন্বয় দেখে। তাই V(G) হলো basis path testing-এর test-সংখ্যা — আর branch coverage-এর জন্য দরকারি ন্যূনতম test-এর একটি ঊর্ধ্বসীমা (অনেক সময় কম test-এই সব edge ছোঁয়া যায়: summary-এ একটিমাত্র ইনপুট [100, 30]-ই সব ১০টি edge ছোঁয়)।

কত হলে বেশি?

McCabe তাঁর ১৯৭৬ সালের প্রবন্ধে একটি module-এর ঊর্ধ্বসীমা হিসেবে ১০ প্রস্তাব করেন, আর NIST-এর ১৯৯৬ সালের প্রকাশনা SP 500-235 (Watson ও McCabe, “Structured Testing”) সাধারণভাবে ১০-কে ভালো সূচনা বলে, অভিজ্ঞ দল আর ভালো test থাকলে ১৫ পর্যন্ত মেনে নেওয়ার কথাও বলে। এটি বৈজ্ঞানিক নিয়ম নয়, অভিজ্ঞতার রীতি। Tool-এর default আলাদা আর সময়ে বদলায় — যেমন লেখার সময়ে ESLint-এর complexity নিয়মের default সীমা ২০ বলে জানি; Python-এর radon-এর মতো tool ১–৫ = A, ৬–১০ = B ধাঁচে শ্রেণি দেয়। সংখ্যা মুখস্থ না করে দলের সীমা config-এ লিখে রাখুন, আর সীমা ছাড়ালে function ভাঙার কথা ভাবুন (পর্ব ৪২-এর refactoring).

৭ · Cognitive complexity আর অন্য মাপ — কোনটি কী বলে

Cyclomatic complexity মূলত test-এর প্রশ্নের উত্তর দেয়: কতগুলো স্বাধীন পথ। কিন্তু মানুষের কাছে কোড কতটা কঠিন, তা শুধু পথের সংখ্যায় ধরা পড়ে না। পর্ব ৪১-এ (Clean code) দেখেছেন guard clause দিয়ে nesting কমালে কোড সহজ হয়, অথচ cyclomatic সংখ্যা একই থাকে। এই ফাঁক পূরণে SonarSource ২০১৭ সালের দিকে G. Ann Campbell-এর লেখা একটি white paper-এ cognitive complexity প্রস্তাব করে। মূল নিয়ম তিনটি (সংক্ষেপে; পূর্ণ নিয়ম white paper-এ):

1. সরল প্রবাহ ভাঙলে +১: if, else if, else, loop, catch, switch (পুরোটায় একবার), একই ধরনের যুক্ত শর্তের প্রতিটি ধারা (a && b && c = +১, a && b || c = +২), recursion.
2. Nesting-এর জন্য বাড়তি: ভেতরে বসানো প্রতিটি if, loop বা catch তার nesting-স্তরের সমান বাড়তি পায়।
3. যা পড়া সহজ করে, তাতে কিছু যোগ হয় না: একটি switch-এর অনেক case, বা ছোট শর্তের সংক্ষিপ্ত রূপ।

// Flat: cyclomatic 4, cognitive 3
function flatFee(a, b, c) {
  let fee = 0;
  if (a) fee += 10;            // +1
  if (b) fee += 20;            // +1
  if (c) fee += 30;            // +1
  return fee;
}
// Nested: cyclomatic 4, cognitive 6
function nestedFee(a, b, c) {
  let fee = 0;
  if (a) {                     // +1
    if (b) {                   // +1 +1 (nesting level 1)
      if (c) fee = 60;         // +1 +2 (nesting level 2)
    }
  }
  return fee;
}

দুটিতেই তিনটি দুই-মুখী decision, তাই cyclomatic ৪ = ৩ + ১. কিন্তু cognitive হিসাবে প্রথমটি ১ + ১ + ১ = ৩, দ্বিতীয়টি ১ + ২ + ৩ = ৬. তিন স্তর ভেতরে গিয়ে পাঠককে তিনটি শর্ত একসাথে মাথায় রাখতে হয় — সংখ্যাটি ঠিক সেই কষ্টকে ধরতে চায়। উল্টো দিকে, ১০টি case-এর একটি switch-এ cyclomatic ১১ (প্রতিটি case-কে +১ ধরলে), কিন্তু cognitive মাত্র ১ — কারণ সারি সারি case পড়া সহজ। SonarQube-এর মতো tool-এর নিয়মে লেখার সময়ে function-প্রতি cognitive সীমার default ১৫ বলে জানি; সংস্করণভেদে যাচাই করে নিন।

কোনো একটি software metric একা কোডের মান বলে না। জটিলতার মাপ সবচেয়ে কাজের প্রবণতা আর তুলনা হিসেবে: কোন function গত ছয় মাসে ক্রমশ জটিল হচ্ছে, কোন ফাইলে complexity বেশি আর বদলও ঘনঘন (hotspot) — refactoring আর বাড়তি test-এর প্রথম প্রার্থী।

৮ · Coverage tool, target আর তার সীমা

বাস্তবে coverage হাতে মাপা হয় না। Tool কোড চালানোর সময় প্রতিটি লাইন বা শাখায় নজর রাখে — হয় interpreter-এর hook দিয়ে (Python-এ sys.settrace, নতুন সংস্করণে sys.monitoring), হয় কোডে গোনার নির্দেশ ঢুকিয়ে (instrumentation), হয় runtime-এর নিজস্ব হিসাব থেকে। লেখার সময়ের পরিচিত কয়েকটি:

• Python — coverage.py: coverage run --branch -m pytest, তারপর coverage report -m (কোন লাইন বাদ পড়ল তার তালিকাসহ) বা coverage html. --branch না দিলে শুধু statement মাপে — এটি অনেকে ভুলে যান।
• JavaScript: Istanbul (CLI-র নাম nyc) কোডে গোনার নির্দেশ ঢোকায়; c8 V8 engine-এর নিজস্ব coverage ব্যবহার করে। Jest-এ --coverage, Vitest-এ coverage provider বেছে নেওয়া যায়। এদের রিপোর্টে সাধারণত statements, branches, functions আর lines — চারটি আলাদা শতাংশ।
• অন্য ভাষা: Java-তে JaCoCo, C/C++-এ gcov বা llvm-cov, .NET-এ coverlet — নাম আর সুবিধা সংস্করণভেদে বদলায়।

[tool.coverage.run]
branch = true          # measure branches, not only lines
source = ["grading"]

[tool.coverage.report]
show_missing = true
fail_under = 80        # exit non-zero below 80% (CI turns red)

এই config-এ CI (পর্ব ৫৮) coverage ৮০%-এর নিচে নামলেই pipeline লাল করবে — একটি quality gate. প্রশ্ন হলো, এমন gate কতটা ভালো?

Goodhart-এর ফাঁদ: ১০০% coverage, শূন্য যাচাই

অর্থনীতিবিদ Charles Goodhart ১৯৭৫ সালে মুদ্রানীতির প্রসঙ্গে একটি পর্যবেক্ষণ দেন, যা পরে নৃবিজ্ঞানী Marilyn Strathern-এর (১৯৯৭) ভাষায় জনপ্রিয় হয়: “যখন কোনো মাপ লক্ষ্যে পরিণত হয়, তা আর ভালো মাপ থাকে না।” এটি Goodhart’s law. Coverage-এ এর সবচেয়ে সোজা রূপ:

def test_grade_everything():
    grade(98, True)      # runs the clamp branch
    grade(30, False)     # runs the no-bonus and FAIL branches
    # no assert: 100% statement and 100% branch coverage, catches nothing

অংশ ৩-এর Suite ৩-এর ইনপুট, তাই coverage tool ১০০% দেখাবে। কিন্তু grade সব ক্ষেত্রে "PASS" ফেরত দিলেও এই test পাস করবে — এটি একটি assertion-free test. Coverage বলে লাইনটি চলেছে; ফল যাচাই হয়েছে কি না, বলে না। আরও কিছু সীমা:

• বাদ পড়া কোড দেখা যায় না: requirement-এ আছে কিন্তু কেউ লেখেননি (ধরুন অনুপস্থিত শিক্ষার্থীর নিয়ম) — না-লেখা লাইনের coverage মাপা যায় না। এখানে কাজে লাগে পর্ব ৪৭-এর black-box কৌশল।
• ইনপুটের মান দেখে না: marks >= 40-এর দুই শাখা ৯০ আর ১০ দিয়েও ঢাকা যায়; ভুল করে > 40 লেখা থাকলে ধরা পড়ে শুধু ৪০ দিয়ে — boundary value.
• শেষের কয়েক শতাংশ সবচেয়ে দামি: ডিস্ক ভরে যাওয়া বা network ছিঁড়ে যাওয়ার error-handling পথ ঢাকতে test double লাগে (পর্ব ৪৯, Test double), আর জোর করে ১০০% চাইলে মানুষ ভঙ্গুর test লেখেন।

৯ · Mutation testing — test-এর test

Coverage প্রশ্ন করে, “test কোডটি চালিয়েছে?” Mutation testing প্রশ্ন করে, “কোডে ভুল থাকলে test কি ধরত?” পদ্ধতিটি সরল: আসল কোডে একটিমাত্র ছোট পরিবর্তন করে একটি নতুন সংস্করণ — mutant — বানানো, তারপর পুরো test suite চালানো।

• Mutation operator: পরিবর্তনের নিয়ম। Relational (>= → >, < → <=), arithmetic (+ → -, * → /), logical (&& → ||, শর্ত উল্টানো !), constant (40 → 41, 0 → 1), statement মুছে ফেলা, return-এর মান বদলানো।
• Killed: অন্তত একটি test fail করেছে — test suite ভুলটি ধরেছে। ভালো খবর।
• Survived: সব test পাস — ভুলটি কেউ ধরেনি। হয় test দুর্বল, নয়তো mutant-টি equivalent.
• Equivalent mutant: লেখা আলাদা, কিন্তু কোনো ইনপুটেই আচরণ আলাদা নয় — কোনো test একে মারতে পারবে না। এটি চেনা সাধারণভাবে undecidable সমস্যা, তাই প্রায়ই মানুষকে দেখে ঠিক করতে হয়।

নিচের stepper-এ একটি কাল্পনিক নিয়ম: অনুপস্থিত হলে ফেল; নম্বর + বোনাস, সর্বোচ্চ ১০০; মোট ৪০ বা তার বেশি হলে পাস। Mutant M1-এ >= বদলে > করা হয়েছে:

1function isPass(marks, bonus, absent) {2  if (absent) return false;3  const total = Math.min(marks + bonus, 100);4  return total >= 40;5}M1  return total > 40;   // mutant

এবার পাঁচটি mutant, চার ধরনের operator. প্রোগ্রামটি আসল function-এর লেখা (string) থেকে একটি অংশ বদলে mutant বানায়, প্রতিটির ওপর দুটি suite চালায়, আর score ছাপে। আসল tool-ও মূলত এমনই করে — তবে syntax tree বা bytecode-এর স্তরে:

// Fictional rule: absent -> fail; total = marks + bonus, capped at 100; pass if total >= 40
const ORIGINAL = `if (absent) return false;
const total = Math.min(marks + bonus, 100);
return total >= 40;`;
const MUTANTS = [                               // [name, operator, find, replace]
  ["M1", "relational  >= to >",    "total >= 40", "total > 40"],
  ["M2", "constant    40 to 41",   ">= 40", ">= 41"],
  ["M3", "arithmetic  + to -",     "marks + bonus", "marks - bonus"],
  ["M4", "logical     negate if",  "if (absent)", "if (!absent)"],
  ["M5", "constant    100 to 101", ", 100)", ", 101)"],
];
const make = body => new Function("marks", "bonus", "absent", body);
const isPass = make(ORIGINAL);
const WEAK = [[75, 0, false, true], [20, 0, false, false]];
const STRONG = [...WEAK, [40, 0, false, true], [38, 2, false, true], [90, 0, true, false]];
const EQUIVALENT = new Set(["M5"]);            // decided by a human: no input can tell M5 apart
function run(name, suite) {
  console.log(`--- ${name} suite (${suite.length} tests) ---`);
  for (const [m, b, a, want] of suite)          // the suite must pass on the original
    if (isPass(m, b, a) !== want) throw new Error("bad test");
  let killed = 0;
  for (const [id, op, find, repl] of MUTANTS) {
    const mutant = make(ORIGINAL.replace(find, repl));
    const failing = suite.find(([m, b, a, want]) => mutant(m, b, a) !== want);
    if (failing) killed++;
    const tag = failing ? `killed by (${failing.slice(0, 3)})` :
      EQUIVALENT.has(id) ? "survived (equivalent)" : "SURVIVED";
    console.log(`${id} ${op.padEnd(22)} ${tag}`);
  }
  const score = killed / (MUTANTS.length - EQUIVALENT.size);
  console.log(`mutation score = ${killed}/(${MUTANTS.length}-${EQUIVALENT.size}) = ${(100 * score).toFixed(0)}%`);
}
run("weak", WEAK);
run("strong", STRONG);

--- weak suite (2 tests) ---
M1 relational  >= to >    SURVIVED
M2 constant    40 to 41   SURVIVED
M3 arithmetic  + to -     SURVIVED
M4 logical     negate if  killed by (75,0,false)
M5 constant    100 to 101 survived (equivalent)
mutation score = 1/(5-1) = 25%
--- strong suite (5 tests) ---
M1 relational  >= to >    killed by (40,0,false)
M2 constant    40 to 41   killed by (40,0,false)
M3 arithmetic  + to -     killed by (38,2,false)
M4 logical     negate if  killed by (75,0,false)
M5 constant    100 to 101 survived (equivalent)
mutation score = 4/(5-1) = 100%

Tool আর খরচ

লেখার সময়ের পরিচিত tool: Java-তে PIT (PITest), JavaScript/TypeScript আর C#-এ Stryker-এর বিভিন্ন সংস্করণ, Python-এ mutmut বা cosmic-ray. নাম আর সুবিধা বদলায়; operator-এর তালিকা আর রিপোর্টের ধাঁচ documentation-এ মিলিয়ে নিন। খরচই বড় বাধা: প্রতিটি mutant-এ test suite চালাতে হয়। ১,০০০ লাইনের module-এ কয়েকশো mutant হতে পারে; suite ২ মিনিটের হলে ৫০০ mutant মানে সবচেয়ে খারাপ ক্ষেত্রে ১,০০০ মিনিট। কমানোর কৌশল: শুধু বদলানো লাইনে mutant (diff-ভিত্তিক), প্রতিটি mutant-এ শুধু সেই test যা ওই লাইন ছোঁয় (coverage তথ্য দিয়ে), প্রথম fail-এই থামা, নমুনা বেছে নেওয়া, আর রাতে বা সপ্তাহে একবার পূর্ণ run. আর survived mutant-এর তালিকা পড়ে সিদ্ধান্ত নিতে মানুষের সময়ও খরচ।

১০ · AI-এর যুগে — coverage বাড়ানো সহজ, test ভালো করা কঠিন

“এই ফাইলের coverage ১০০% করে দিন” — এমন অনুরোধে AI খুব দ্রুত কাজ করে, আর ঠিক এখানেই Goodhart-এর ফাঁদ সবচেয়ে গভীর। AI প্রায়ই এমন test লেখে যা function ডাকে কিন্তু কিছু যাচাই করে না, অথবা কোড পড়ে তার বর্তমান আচরণই প্রত্যাশা হিসেবে লিখে দেয় — implementation-এর প্রতিচ্ছবি। তখন bug-ও “প্রত্যাশিত” হয়ে যায়। আবার complexity-র হিসাব চাইলে AI আত্মবিশ্বাসের সাথে ভুল E বা N গোনে, অথবা coverage tool-এর এমন flag বলে, যা আসলে নেই।

AI-এর সাহায্যে test আর metric — চেকলিস্ট

• AI-লেখা প্রতিটি test-এ নির্দিষ্ট মানের assertion আছে, আর প্রত্যাশা specification থেকে এসেছে
• কোডে হাতে একটি ছোট ভুল (>= → >) ঢুকিয়ে দেখেছি test fail করে; পরে ভুলটি ফিরিয়ে নিয়েছি
• Coverage --branch mode-এ মেপেছি, শুধু line-এ নয়
• AI-এর দেওয়া V(G) বা ন্যূনতম test-সংখ্যা নিজে CFG এঁকে মিলিয়েছি
• Tool-এর flag আর config অফিসিয়াল documentation-এ মিলিয়েছি, একটি throwaway branch-এ চালিয়েছি
• Prompt-এ কোনো secret বা ব্যক্তিগত তথ্য পাঠাইনি; অন্য উৎসের কোড এলে license দেখেছি