Skip to content

STARChatterboxBackend: configurable mock responses for query methods #934

@BioCam

Description

@BioCam

Context

STARChatterboxBackend overrides query methods (like head96_request_tip_presence, core_check_resource_exists_at_location_center, request_presence_of_carriers_on_deck, etc.) with hardcoded return values. This works for basic simulation but doesn't let users customize simulation behavior for different scenarios without subclassing.

Proposal

Add a standardised pattern where query methods accept a mock_response parameter with a sensible default, allowing users to configure simulation parameters per-instance. For example:

async def head96_request_tip_presence(self, mock_response: int = 0) -> int:
    return mock_response

Design questions to resolve

  1. Per-call vs per-instance: Should mock_response be a method parameter (configurable per call) or an instance attribute set at init/setup time (configure once, return consistently)?
  2. Signature compatibility: The base class signatures don't have mock_response, so this parameter is only usable when calling directly on STARChatterboxBackend. Is that acceptable, or do we need a different approach?
  3. Scope: Which methods should get this treatment? All query methods, or only the ones that return parsed data?
  4. Naming convention: mock_response, simulated_value (already used by channel_dispensing_drive_request_position), or something else?

Affected methods (current hardcoded returns)

  • head96_request_tip_presence()0
  • core_check_resource_exists_at_location_center()True
  • request_presence_of_carriers_on_loading_tray()[]
  • request_presence_of_carriers_on_deck()[]
  • request_tip_presence() → tip tracker state
  • request_z_pos_channel_n()285.0
  • channel_dispensing_drive_request_position()0.0 (already has simulated_value param)
  • request_iswap_initialization_status()True
  • request_pip_height_last_lld()list(range(12))

Note: channel_dispensing_drive_request_position already implements this pattern with simulated_value — that could serve as the starting point for a consistent convention.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions