Running integration tests with mock hardware

[URJala]

Added some launch arguments and some checks to avoid connecting to the dashboard interface when using mock hardware, as that will not work. Maybe not the most elegant, but it works for now. Currently passthrough controller does not work at all with mock hardware, and is bypassed if using that in the test. test_trajectory_scaled_aborts_on_violation fails, as the hardware doesnt abort. test_set_io also fails as the controller cant verify that a pin has been set.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 18.56%. Comparing base (1b121b7) to head (3201f73).
⚠️ Report is 478 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##            main    #1226       +/-   ##
==========================================
+ Coverage   3.59%   18.56%   +14.97%     
==========================================
  Files         13       33       +20     
  Lines        947     3409     +2462     
  Branches     152      421      +269     
==========================================
+ Hits          34      633      +599     
- Misses       843     2745     +1902     
+ Partials      70       31       -39     

Flag	Coverage Δ
unittests	18.56% <ø> (+14.97%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[urfeex]

I think it is a good idea to split up the robot_driver test into individual tests.

However, I think it would be beneficial to be able to specify mock hardware outside of the test parametrization. This way, we can run the mock hardware tests also when the integration tests flag is not set. This would effectively allow running some tests on the buildfarm, as well.

[urfeex]

This seems fine so far and I think with renaming all the tests I would be fine with merging this. There is more potential for refactoring things like the initialization, but for this PR I think it's fine to leave it like that.

[urfeex]

Shouldn't this test also be able to run on mock hardware? I see, it doesn't, but I don't see a conceptual reason why it shouldn't.

[URJala]

There is no real reason that it shouldn't, but with the way the controller sets io's, it apparently cannot verify if a pin was set, and fails the test because the pins indeed end up at the wrong value. The controller also prints a little warning that this can happen with mock hardware, so I don't think it should be tested, as it doesn't behave correctly.