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
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
property-based-testing.mdskills/software-testing/references/
Property-Based Testing Reference
When to Use
Use property-based tests when example lists become unwieldy and behaviour is better expressed as an invariant:
- Ordering preservation
- Idempotence
- Reversibility
- Monotonicity
- Conservation
- Parser round-trips
- Commutativity where appropriate
- State machine properties
When Not to Use
Avoid when:
- The property is too weak or too broad
- The property secretly re-implements the algorithm under test
- Examples are clearer and sufficient
Complement, Don't Replace
Property tests complement example tests. Named examples document key cases. Property tests cover input spaces humans systematically miss.
Practical Tips
- Start with a simple property and strengthen it
- Use shrinking to find minimal failing cases
- Combine with example-based tests for documentation
- Watch for properties that pass vacuously (always true because generator is too constrained)