Improve testing of the Rust code

[imobachgs]

Problem

Testing our Rust code is kind of tricky. Many times, the code has to interact with the underlying system (systemd, NetworkManager, etc.) which makes hard even to test logic that it is not directly related.

Solution

• Write a set of builders that allows to spawn services replacing some parts with testing versions. They allow to create services replacing the "adapters" (e.g., using a dummy network adapter).
• Add a set of test_utils modules with some utilities to use during tests.
• Expand the current tests, going from 21% to 26%.

Testing

• Expanded the test coverage.

Follow-up

• Create a test adapter for the software service.
• Consider to do not inject any service by default in the builders. I would allow to replace any piece, but it is not needed by now.

[jreidinger]

I have to say that I do not like much the change that basically make Builder to call spawn. It does not make much sense for me to say "Builder spawn service". if we go this way I would prefer to follow convention and have usual "new->with_*->build" flow for builder and for spawning having dedicated spawner or have it as method in that service like ServiceBuilder::new().build()?.spawn()?
This way it is inconsistent with rest of rust builder and is just confusing.

[imobachgs]

I see your point. Perhaps we need a better name instead of having a separate concept for spawning the service. For instance, Rust Command follows the builder pattern too, but it has better naming.

[imobachgs]

Actually, you always spawn the service. After all, you communicate with it through messages. So I do not see the point of having separate build and spawn methods. Perhaps something like Launcher and launch. I do not like Spawner because the word does not exist :-) But I am open to other suggestions (perhaps something related to actors).

[jreidinger]

Launcher and launch sounds good to me. I just find confusing to have Builder and spawn. Alternative can be also "Starter"/"start" or "Bootstrap"/"start" or "Runner"/"run"

[jreidinger]

same note as above. In this case it is even more visible that it do building ( aka setting defaults for not specified stuff ) and then spawning together with service setup. Which I see as different tasks.

[imobachgs]

For me it is similar to the standard Command struct.

[jreidinger]

In that case I would not call it Builder but Task. as you spawn tasks and not Builder

[jreidinger]

is there some magic to avoid compilation of this or should be here #cfg[test] ?

[imobachgs]

No, it cannot be #cfg[test] because it cannot be used by other crates. The solution could be to put it behind a feature flag, but I decided to stop here (I think we have more urgent things to work on at this moment). But it could be a nice task for a Friday afternoon.