Skip to content

ADR-014 - CRM API Usage and Mocking Strategy

Statusaccepted
Date2025-04-14
Decision MakersDardan Bujupaj (AX), Marc Gähwiler (AX), Markus Brenner (Griesser)

Context

The Sunny Calculator AddOn relies on CRM APIs. To enable parallel development and testing while some APIs might not be immediately available, we need a clear strategy for API interaction and mocking. The goal is to allow AddOn development to proceed efficiently.

Decision

The Sunny Calculator AddOn team will:

  1. Prioritize Existing CRM APIs: Utilize existing CRM APIs where applicable.

  2. Propose New/Modified CRM APIs: Collaborate with the CRM team to define necessary new or modified APIs, including specifications for functionality, input, and output.

  3. Implement Realistic API Mocking: Create and use realistic mocks of agreed-upon CRM APIs for development and testing purposes. These mocks will simulate expected data, error conditions, and different scenarios.

  4. Utilize Mocks for Testing: Employ these mocks for unit testing (AddOn backend), integration testing (frontend & backend), and potentially early system testing.

Consequences

This approach offers the following:

  • Positive:

    • Enables parallel AddOn and CRM API development, accelerating delivery.
    • Provides early feedback on API design.
    • Facilitates comprehensive testing at various levels.
    • Reduces development blocking due to API availability.
    • Creates reusable test assets.
  • Negative:

    • Requires effort for mock creation and maintenance.
    • Potential for discrepancies between mocks and real APIs, necessitating thorough integration testing.
    • Requires close coordination between AddOn and CRM teams.

Alternatives

Considered alternatives:

  • Sequential Development: Wait for full CRM API completion before AddOn development.

    • Pros: Lower risk of integration issues.
    • Cons: Significant project delays.
  • Contract-First Development (No Mocks): Develop based on API specifications without simulated responses.

    • Pros: Focus on API design.
    • Cons: Hinders early AddOn development and testing.
  • Minimal API Stubs: Use basic stubs with limited functionality.

    • Pros: Lower initial effort.
    • Cons: Insufficient for effective testing and early issue detection.