Skip to content

Improve mock-ability of CmdMessenger and Queues #56

Description

@DocMoebiuz

I am experiencing an issue with CmdMessenger when implementing integration tests where I would like to confirm that the message that is sent to the arduino is really having the right format, or make sure that CmdMessenger sendCommand is called the way it should be called.

Here is what works well:

  • ITransport - interface is available and i can easily mock it and initialize CmdMessenger with the mock - this way I can verify that .write eventually contains the right payload - I am using it to validate payload, and also to verify that writes were triggered correctly, e.g. to test my cache layer.

Here is what doesn't work well:

  • CmdMessenger is lacking an interface definition and cannot be easily mocked in tests.
  • Queues are running on a timer which is problematic for the tests and can cause flaky tests. Adding waits to the unit tests also artificially increases test run time.

Here is what I would like to do:

  • It would be great if we could inject our own queue, or skip the queuing altogether in the context of testing. Then I could remove all my 100ms wait times in the code.
  • CmdMessenger should have an interface so that we can replace cmdMessenger entirely with a mocked object. It might make mocking queues and transport even obsolete... because we could simply verify on cmdMessenger level that it's called correctly.

You might say I should not test the raw payload - but tbh honest, in many cases this kind of integration test makes sense because we have this physical boundary between PC and microcontroller, desktop app code and firmware code. The message format is the contract between each domains.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions