CtrlK
BlogDocsLog inGet started
Tessl Logo

evilissimo/software-design

Use before implementing or refactoring software. Contains two skills: (1) Modular Software Design — for designing module boundaries, APIs, layers, abstractions, services, repositories, adapters, or architecture, helping reduce total system complexity by creating deep modules, hiding implementation knowledge, avoiding leakage and pass-through APIs, comparing alternative designs, documenting interfaces before coding, and critiquing existing architecture; and (2) Software Testing — for writing unit tests, integration tests, or end-to-end tests, creating mocks/stubs/fakes, designing a testing strategy, doing TDD, reviewing test quality, fixing flaky tests, or refactoring test suites, generating risk-focused test plans, picking appropriate test levels, choosing between mocks/fakes/real dependencies, and applying Arrange-Act-Assert patterns with concrete examples.

88

Quality

88%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

coverage-criteria.mdskills/software-testing/references/

Coverage Criteria Reference

Statement Coverage

Asks whether executable statements ran. Weakest criterion; a statement can run without revealing a bug in it.

Branch Coverage

Asks whether each branch or decision outcome ran. Subsumes statement coverage in straightforward control flow.

Condition Coverage

Asks whether each atomic condition has been true and false.

Path Coverage

Asks whether complete paths ran. Quickly becomes infeasible with loops.

Prime Path Coverage

Stronger but more practical than full path coverage. Covers paths up to simple cycles.

Input-Space Coverage

Partitions the domain into equivalence classes or combinations of characteristics and deliberately samples them. Boundary values are especially bug-prone.

Mutation-Oriented Thinking

Asks whether tests would detect small plausible faults. Treat as a stronger adequacy criterion or "gold standard" for comparing other criteria.

Usage Guidance

  • Use coverage to find blind spots and assess risk.
  • Do not treat coverage percentage as the goal.
  • High coverage can coexist with weak assertions and no real bug-finding power.
  • Coverage is most useful when it tells you where your reasoning may be incomplete.

skills

tile.json