Skip to content
  • 3 min read

Pattern Comparison and Testing Strategies

Simple English (B1). Comparisons help you pick a pattern. Testing proves the boundaries behave as designed.

Pattern Comparison

Strategy vs State

Aspect Strategy State
What changes The algorithm used Behavior by lifecycle phase
Who picks Caller passes a strategy Object moves itself by rules
Example Payment provider plug-in Order: Pending → Paid → Shipped

Factory vs Builder

Aspect Factory Builder
Job Create one product type Build one complex object step by step
When Runtime type from config Many optional parts, fluent setup

Decorator vs Inheritance

Aspect Decorator Inheritance
Binding Runtime, stackable Compile-time class tree
When Add behavior around existing object Clear IS-A and Liskov rules

Adapter vs Facade

Aspect Adapter Facade
Goal Match a foreign interface Hide a complex subsystem
When Legacy or third-party API One entry for many calls

Observer vs Pub/Sub

Aspect Observer Pub/Sub
Links Subject knows observers Producers and consumers know only the bus
Scope Usually one process Often many processes or services

Testing Strategies for Patterns

Unit Tests

Test one unit. Replace dependencies with fakes or mocks. The pattern boundary is often a mock boundary.

from unittest.mock import MagicMock

def test_order_service_calls_repository() -> None:
    repo = MagicMock()
    svc = OrderService(repo=repo)
    svc.place_order("ORD-1", 99.0)
    repo.save.assert_called_once()

Rule: mock the port (interface), not random internals.

Integration Tests

Use real collaborators for the slice you care about. No mocks across that slice.

def test_place_order_persists(real_db_session) -> None:
    repo = SQLAlchemyOrderRepository(real_db_session)
    svc = OrderService(repo=repo)
    svc.place_order("ORD-1", 99.0)
    assert repo.find_by_id("ORD-1") is not None

Contract Tests

Consumer and producer agree on the API shape. Tools like Pact record expectations and verify in CI.

Property-Based Tests

Many random inputs; check invariants (e.g. amount always positive).

from hypothesis import given
from hypothesis import strategies as st

@given(amount=st.floats(min_value=0.01, max_value=1_000_000, allow_nan=False))
def test_order_amount_valid(amount: float) -> None:
    order = Order(id="x", amount=amount)
    assert order.is_valid() is True

Mutation Testing

Tools change your code (== to !=, delete lines). If tests still pass, coverage is weak. Use scores as a guide, not a religion.

Decision Hints (Not Rules)

  • Many algorithms, one interface → Strategy.
  • Unknown object type at runtime (config/input) → Factory.
  • Object phases with different rules → State.
  • One complex build with options → Builder.
  • Add optional cross-cutting behavior at runtime → Decorator.
  • One producer, many in-process listeners → Observer.
  • Request passes ordered handlers (auth, limit, validation) → Chain.
  • Unknown external API → Adapter.
  • Many internal calls, one call for clients → Facade.

Pair each pattern with the right test level: unit for pure logic, integration for real I/O, contracts for API stability.