Build simpler executable for just tests

[gavanderhoorn]

As per title.

Work towards #173.

Instead of starting up a full MotoROS2, exit immediately after running the unit tests.

Less work than a fully separate test VS project, but achieves some of the same goals (rapid iteration).

[ted-miller]

I don't understand the purpose of this PR. IIUC, to run the tests:

• Build w/ testing-flag enabled
• Install .out file
• Boot to run logical tests
• Rebuild w/ testing-flag disabled
• Install new .out file
• Boot for normal mode to do physical tests

That's a rather time consuming process.

I understand the idea of having a dedicated executable for running unit tests against the main MR2 executable. But why wouldn't you want to leave the MR2 program running after the tests?

[gavanderhoorn]

why wouldn't you want to leave the MR2 program running after the tests?

because I'm working on some code for which I want to be able to quickly run some new tests, without having to wait for the "whole" startup sequence to complete.

With the proposed changes, after running the tests, it all just shuts down immediately. That's a 3 second total run time on my YRC1.

[ted-miller]

because I'm working on some code for which I want to be able to quickly run some new tests, without having to wait for the "whole" startup sequence to complete.

As in you're pushing a new .out file and loading it through the console?
This isn't something that anyone else would be able to do.

[gavanderhoorn]

As in you're pushing a new .out file and loading it through the console? This isn't something that anyone else would be able to do.

We probably also don't expect non-developers to ever run the unit tests.

Personally I would not mix testing with regular usage, even when developing, but I get the impression you do. That would indeed be impossible with these changes.

[ted-miller]

We probably also don't expect non-developers to ever run the unit tests.

IMO, if you put something open-source in a public repo, it should be useable by anyone.

I would not mix testing with regular usage, even when developing, but I get the impression you do

Maybe not best practice, but generally yeah.

[gavanderhoorn]

I would not mix testing with regular usage, even when developing, but I get the impression you do

Maybe not best practice, but generally yeah.

Ok, well then this PR can't be merged.

We should really address #173 then.