Test Design Patterns

Test Design Patterns — Systematic Test Design Guide

Methodologies for systematically deriving and effectively structuring test cases.

Test Case Derivation Techniques

1. Equivalence Partitioning

Input: Age (integer 1-150)
+-- Valid class: [1, 150] -> representative: 25
+-- Invalid class 1: < 1   -> representative: 0, -1
+-- Invalid class 2: > 150 -> representative: 151, 999
+-- Invalid class 3: non-integer -> representative: 25.5, "abc"
+-- Invalid class 4: null  -> representative: null, undefined

2. Boundary Value Analysis

Range: [1, 150]
Test values: 0, 1, 2, ... , 149, 150, 151
             ^  ^  ^        ^    ^    ^
          invalid boundary valid  valid boundary invalid

3-point boundary: min-1, min, max, max+1
7-point boundary: min-1, min, min+1, nominal, max-1, max, max+1

3. State Transition Testing

Order state transitions:
CREATED -(payment)-> PAID -(shipping start)-> SHIPPING -(delivery)-> DELIVERED
   |                  |                         |                      |
   +-(cancel)-> CANCELLED  +-(refund)-> REFUNDED  +-(return)-> RETURNED  +-(return)-> RETURNED

Test cases:
1. Happy Path: CREATED -> PAID -> SHIPPING -> DELIVERED
2. Order cancel: CREATED -> CANCELLED
3. Post-payment refund: CREATED -> PAID -> REFUNDED
4. In-transit return: CREATED -> PAID -> SHIPPING -> RETURNED
5. Invalid transition: CANCELLED -> PAID (should be rejected)
6. Invalid transition: DELIVERED -> SHIPPING (should be rejected)

4. Pairwise Testing

Parameters:
- OS: Windows, macOS, Linux
- Browser: Chrome, Firefox, Safari
- Language: ko, en, ja

Full combinations: 3x3x3 = 27
Pairwise: Reduced to 9 (covers all 2-way combinations)

| # | OS      | Browser | Language |
|---|---------|---------|----------|
| 1 | Windows | Chrome  | ko       |
| 2 | Windows | Firefox | en       |
| 3 | Windows | Safari  | ja       |
| 4 | macOS   | Chrome  | en       |
| 5 | macOS   | Firefox | ja       |
| 6 | macOS   | Safari  | ko       |
| 7 | Linux   | Chrome  | ja       |
| 8 | Linux   | Firefox | ko       |
| 9 | Linux   | Safari  | en       |

5. Decision Table

Discount rules:
Condition                    | R1 | R2 | R3 | R4 |
-----------------------------+----+----+----+----+
VIP member?                  | Y  | Y  | N  | N  |
Order amount >= $50?         | Y  | N  | Y  | N  |
-----------------------------+----+----+----+----+
15% discount                 | X  |    |    |    |
10% discount                 |    | X  | X  |    |
No discount                  |    |    |    | X  |

Test Structure Patterns

AAA (Arrange-Act-Assert)

def test_order_total_with_discount():
    # Arrange
    order = Order(items=[Item("A", 10000), Item("B", 20000)])
    discount = PercentageDiscount(10)

    # Act
    total = order.calculate_total(discount)

    # Assert
    assert total == 27000

Given-When-Then (BDD)

def test_vip_customer_gets_extra_discount():
    # Given: A VIP customer places an order of $50 or more
    customer = Customer(tier="VIP")
    order = Order(customer, total=60000)

    # When: Discount is applied
    discounted = pricing_service.apply_discount(order)

    # Then: 15% discount is applied
    assert discounted == 51000

Builder Pattern (Test Data)

class OrderBuilder:
    def __init__(self):
        self._customer = default_customer()
        self._items = []
    def with_vip_customer(self): ...
    def with_item(self, name, price): ...
    def build(self) -> Order: ...

# Usage
order = OrderBuilder().with_vip_customer().with_item("A", 10000).build()

Test Pyramid Ratio Guide

        / E2E  \          5-10%   Slow but realistic
       /--------\
      / Integration \     20-30%  Inter-service integration
     /--------------\
    /  Unit Tests    \    60-70%  Fast and isolated
   /------------------\

Risk-based Test Prioritization

Risk = Failure Probability x Business Impact

       High Impact
          |
  P1 Tests | P0 Tests
  (Must)   | (Top Priority)
  ---------+----------> High Probability
  P3 Tests | P2 Tests
  (If time)| (Recommended)
          |
       Low Impact