No suite concept defined

[PeterFromSweden]

I cannot find support of building a test suite that merges all tests into a monolith that runs them all.
For that different setup/teardowns must coexist which seems unsupported.
We are using both target and host based suite tests that tests all tests in one go.

[mvandervoord]

Hi! You're not finding instructions for this because it's not the way Unity was meant to be used. This is actually an intentional decision.

Unity is a unit test framework. It's purpose is to test each C module (unit) as deeply as it's able. As such, it is often necessary to control and/or monitor the modules that the unit under test interfaces with. On the simplest side, it means stubbing out a few functions. In more complex cases, it might mean getting into mocking. In either case, you're creating a fake version of another module's API.

C (as you know) is a statically linked language. If I have a global function named CheeseCurls, it's the ONLY global function named CheeseCurls. Therefore, if I need make a fake version of CheeseCurls to help test my FillTheBag function, then I can't also link to the real version of CheeseCurls to make sure it also works. It becomes a linking problem

Unity simplifies all this by linking each test module as its own executable. It then relies on the build system to either summarize the results on its own or call Unity's summarize function. Ceedling, for example, collects all the individual results and generates reports for the entire suite.

You mentioned that you're running tests on the target and the host as well. If you haven't already, you might be interested in checking out Ceedling. With some configuration, it can often be used to generate your executables, push them onto a simulator or target, run them, and then gather the results. Repeat for each test module.

(The next thing I will note is that unit testing on your target is also limiting if you're directly writing to registers, etc... instead it's better to abstract them away so you are again in full control of your test environment.). :)

[PeterFromSweden]

Hi!

If you can build for host based unit testing, then you can of course also build for target based unit testing! It adds value, right?

On target it is convenient to flash one single suite that tests all unit tests in a sequence. That is more convenient and time effective than flashing them one by one, right? This is important when using CI/CD pipeline so every pull request triggers a complete target unit test cycle automatically.

So that is what we do since 20 years and there is no problem. Other frameworks supports this use case. Also with local setup/teardown that does not need to be global functions. If you are interested I can describe how that is achived.

We have an abstraction layer to hardware so implementation testing of that will be done in other manner, but that is not the topic here.