accordant-patterns

Common Patterns in Accordant

This skill covers frequently-used patterns when building Accordant specs.

Response-Dependent State

When state depends on server-generated values (IDs, timestamps, ETags):

spec.Operation<CreateOrderRequest, ApiResult<Order>>("CreateOrder", (request, state) =>
{
    return Expect.That<ApiResult<Order>>(
               r => r.IsSuccess && !string.IsNullOrEmpty(r.Data.OrderId))
           .ThenState<AppState>(
               // Lambda receives response AND a pre-cloned nextState
               (ApiResult<Order> response, AppState nextState) =>
                   nextState.Orders[response.Data.OrderId] = new OrderState
                   {
                       Product = request.Product,
                       Status = OrderStatus.Created
                   },
               // Mock for test generation (no real system running)
               mock: () => new ApiResult<Order>
               {
                   Data = new Order 
                   { 
                       OrderId = Guid.NewGuid().ToString(),
                       Product = request.Product 
                   },
                   StatusCode = 201
               });
});

Why the Mock?

During test generation, there's no real server. The mock provides a plausible response so Accordant can explore the state space. At test execution, the mock is ignored — real responses are used.

Validating Captured Values

spec.Operation<string, ApiResult<Order>>("GetOrder", (orderId, state) =>
{
    if (!state.Orders.TryGetValue(orderId, out var order))
        return Expect.That<ApiResult<Order>>(r => r.IsNotFound).SameState();

    // Validate against captured state
    return Expect.That<ApiResult<Order>>(
               r => r.IsSuccess && 
                    r.Data.OrderId == orderId &&
                    r.Data.Product == order.Product &&
                    r.Data.Status == order.Status)
           .SameState();
});

Request Derivations