Following the best-practise for organising code for unit testing

Libraries
1

Is it possible to have code from one module in the /lib folder link to code in another module also in /lib?

Our local code is currently all in the /src directory, meaning that we have to use the test_build_src flag to be able to run the unit tests.

Best-practise says we should break the code out into modules in the /lib folder, which would be much neater because it would allow us to put platform-specific code into separate libraries from “core” code. We also have multiple versions of our product to be deployed in different vehicles, each of which has vehicle-specific code which we’d love to keep organised in separate libraries.

The problem is that the platform-specific code or vehicle-specific code needs to implement interfaces declared in the core library so that they can be configured/injected by a file in /src. It appears that each library in the /lib folder is compiled separately, so the platform-specific files can’t link to the interfaces and the build fails.

We don’t want to publish any of the modules to the package library as they’re private and specific to our app (and they’re under active development so we wouldn’t want to have to publish new versions each time there’s a change to a bit of code).

Are we missing something obvious? A build flag or platformio.ini setting maybe?

2
  1. Yes, keep libraries/components in the lib folder. They will be available for Unit Testing too.
  2. LIbraries/components in the lib folder can depend on each other. Just use the correct #include
  3. Use multiple [env:***] in a project-specific to your vehicle. Then ignore unwanted libs/components with lib_ignore.
  4. It is also possible to do extra scripting for lib/components and dynamic SRC_FILTER. See docs for examples.
3

Thank you very much Ivan, let me give that a try. When I moved things into the lib folder they were unable to #include files from others in the lib folder so I must have done something wrong. I’ll try again.

Thank you!

4

You were absolutely correct Ivan. I was using CLion, and on moving things into the lib folder nothing was resolvable inside the IDE any longer. I’d introduced a handful of #include path errors, which caused some compiler errors but it looked much worse than it actually was, because CLion was in total disarray. It couldn’t find anything, despite me telling it to re-index and to reload from CMake.

What I actually needed to do was Tools > PlatformIO > Re-Init. Once I’d done that it picked up the extra lib folders and I could narrow down the small number of #include errors that needed fixing.

Thanks again!

5

We have very basic integration with CLion which is still in development and is not recommended for production use. Please VSCode or native PIO Core CLI.

6

As a discipline I always use the CLI for all languages and frameworks - much more portable and the familiarity helps with CI and easy enough as a Linux person. But the syntax highlighting and code navigation in the IDE is valuable, and the jetbrains IDEs have a consistent UI, keybindings etc - so switching from Dart to c++ to php etc is made much easier by sticking with the one vendor.

The Clion plugin does everything you need if you’re comfortable with CLI too. The only painful thing is that you need to add your own CMakeListUser.txt file content so that it recognises the /test sources too: https://youtrack.jetbrains.com/issue/CPP-21173/Integration-of-tests-in-plugin-PlatformIO-for-CLion#focus=Comments-27-4356982.0-0
So I’m very happy with it really!

7

Please provide PR to

We notice a bad user experience when people use PlatformIO + CLion. It seems we should deprecate CLion integration to avoid bad feedback for PlatformIO or CLion. Both projects are great but the integration is very bad. Sorry.

cc: @elmot