'pio test' fails with "No such file or directory", while 'pio run' builds fine

The behavior looks odd to me, though I am not sure is this a bug or a “by design”.
I’ve encountered it in my personal project, but for the illustration purposes I’ll use platformio-examples/unit-testing/calculator at develop · platformio/platformio-examples · GitHub as a basis.

So, say, I wish to use 3rd party lib in my project.
Thus I include the relevant ‘.h’ file and a dependency
[image #1]

The pio run -e esp32 builds successfully
[image #2 - see below]

Now, the Adafruit ‘.h’ is only referenced in my project’s ‘/src’, and it is not referenced in my embedded tests (well I don’t intend to test it there), but weirdly the pio test -e esp32 fails to execute from this point on. (Just to emphasize, the tests had run successfuly before I added the Adafruit to lib_deps.)
[image #3 - see below]

whereas the failure cause is
.pio/libdeps/esp32/Adafruit BMP280 Library/Adafruit_BMP280.h:26:10: fatal error: Adafruit_Sensor.h: No such file or directory

After some googling around the community and experimenting, I ended up with two possible workarounds, which make the tests successfull again:
[image #4 - see below]

  1. either add lib_ldf_mode = deep to the env config (which is not really reccomended and increases a build time)
  2. or add #include <Adafruit_BMP280.h> to every single test (even though I don’t need it there)

Both workardounds don’t really look like a “sustainable development” to me.
So am I doing anything wrong? Or is it a PIO bug? Or is it the Adafruit issue?

The latter statement I had added due to following observations:

  • The problem reproduces with ‘Adafruit’ library, but doesn’t seem to happen with, say, ‘AccelStepper’.
  • It is not directly related to test-s subsystem: e.g. if the library is added to env lib_deps, while you don’t include .h into the /src/main.cpp, the run fails to build similarily.

Sorry, due to a limitation of a forum board, had to attach other screenshots as the separate posts below

Image #2
image

Image #3
image

Image #4
image

lib_ldf_mode = deep+ is the same?

Correct, the deep+ workarounds the issue just like the deep.

Can you uplaod the project as a whole, e.g. on github?

Please see here https://github.com/hubua/IoT/tree/master/calculator_with_adafruit_issue_example

pio test --environment esp32 fails until you uncomment relevant lines in the ini or cpp files.

Oh yeah I see the issue now. The LDF has a quirk where it will not correctly identify the dependency of a library until you include the library. So the Adafruit_BMP280 library failing the build with Adafruit_BMP280.h not being included is expected.

So, is this the acknowledged LDF bug? Shall it be fixed? The actual behavior is not good.
Also, why doesn’t this bug manifest itself with AccelStepper?

AccelStepper doesn’t have any subdependencies on other libraries, hence it doesn’t matter if the LDF picks them up or not, since there are none. (See source code only depends on Arduino.h, the framework.)

The LDF behavior of scanning your source files for #include files and basing library resolve logic (written in python) around what is found there has been in PlatformIO pretty much forever. Switching it to GCC for more correct behavior is already tracked in Replace LDF deep with native GCC Preprocessor · Issue #3113 · platformio/platformio-core · GitHub. That has been sitting there for so long however that I don’t see that being implemented any time soon.

Thank you very much for your explanation!