Stub Mode for Optical Switch

[zigen]

In order to aid future integration testing and help learn more about how our hardware works, we are building "stub" versions of devices. These do not connect to real hardware, but instead mimic or mock the behavior of those devices in code.

Later on, this will help us define common interfaces for devices, instead of the device-specific interfaces that we have now. It may also help us find better ways to refactor our existing code.

Acceptance criteria

• Stub switch has same public interface as the Thorlabs switch
• Stub switch behavior reflects happy-path behavior for the Thorlabs switch. In other words, the stub replicates the same behavior as the real switch when the switch does not produce any errors.
• All methods have type hints for input variables and return values.
• All public methods have basic docstring documentation explaining the method's behavior clearly. The class may also have docstring documentation.
• Any unclear variables or code is adequately commented.
• pytest unit tests are written for all public methods, with meaningful inputs

[auspicacious]

@master-of-ppap Welcome to Thunderdome. I suggest looking at https://github.com/moonshot-nagayama-pj/PnPQ/pull/23 for an idea of what the final product will look like.

@TomShen1234 Did I miss anything in the acceptance criteria? I am planning on writing a more general "definition of done" in the future.

[TomShen1234]

Looks fine to me right now.

[master-of-ppap]

@master-of-ppap Welcome to Thunderdome. I suggest looking at #23 for an idea of what the final product will look like.

Thank you! Is there any documentation for what the optical switch does/is supposed to do?

[auspicacious]

Is there any documentation for what the optical switch does/is supposed to do?

@hhatpsi and @Marie2222 would be good people to ask about that.

[auspicacious]

Initial stub is done, so I'm marking this as done. After refactoring in https://github.com/moonshot-nagayama-pj/PnPQ/issues/27 we will have more work to do here.