Feature: Add MockHandler for hardware-less simulation

[hitarthium]

Problem
Currently, ScienceLab requires a physical PSLab device to initialize. This makes it difficult to run tests or develop features without hardware.

Proposed Solution
Implement a MockHandler class and a mock=True argument in ScienceLab to simulate device I/O.

[minhpham1810]

Hi @hitarthium ! I’d like to work on this.

Here is my current plan: add a MockHandler implementing ConnectionHandler with minimal responses for GET_VERSION and GET_FW_VERSION, then add mock=True to ScienceLab so it can initialize without hardware. I’ll also add a test that instantiates ScienceLab(mock=True) and verifies firmware/version.

Let me know if you prefer the mock to live under pslab/connection/ or elsewhere, and if you could assign this issue to me. Looking forward to hearing from you.

[hitarthium]

Hi @minhpham1810! Thanks for the interest in this issue.

I actually already implemented this feature and submitted PR #269 a few days ago, which is currently linked to this issue and awaiting review.

Since my PR is already active, feel free to take a look at my implementation in #269 and leave any feedback or suggestions there if you spot potential improvements. I'd appreciate the code review!

[CloudyPadmal]

My opinion is that, I don’t think mocking PSLab is a good idea.

I understand that mocking helps work without the hardware (if we could really implement this mammoth task)

PSLab behaviour is largely defined by custo firmware, timing, and hardware constraints.
A Python mock would either be trivial (and provide false confidence) or evolve into a parallel firmware implementation that will inevitably diverge from reality.

Most real PSLab bugs occur at the firmware–host boundary, which mocking explicitly bypasses.

Instead of mocking the device, it’s better to refactor testable logic away from IO and rely on real hardware or protocol-level tests.

[hitarthium]

Hi @CloudyPadmal, thank you for the detailed insight.
​I completely agree with you—a Python mock can never replicate the complex timing, interrupts, or firmware-host boundary quirks of the real hardware. It definitely shouldn't be relied upon for verifying signal integrity or protocol correctness.
​However, the primary goal of this PR (as mentioned by @mariobehling during the review) is to solve the onboarding and CI barrier. Currently, a new contributor cannot even instantiate the ScienceLab class or run basic sanity tests without having the physical device connected.
​This MockHandler is intended strictly as a development stub to:
​Allow the library to initialize in CI/CD environments where no hardware exists.
​Enable contributors to verify that their API calls (function signatures, type checks) are correct before testing on hardware.
​I can add a clear warning in the docstring stating: "This mode is for API testing only and does not emulate real-time hardware behavior."
​Let me know if that compromise works!