Ceedling 1.0.0 and :support

[CJCombrink]

Quick question just to make sure if I am not missing something while trying to migrate to ceedling 1.0.0:

My project has :paths: -> :support: -> - test/support/** which contains files platform_mocking.h and platform_mocking.c
Without much effort I am able to build the project and run the tests.

When I migrate to ceedling 1.0.0 and add the :paths: -> :support: -> - test/support/** to my project I get linker errors for all test files that does not include the mock file

#include "mock_platform_mocking.h"

The error undefined reference to XXX for each function in the platform_mocking.h header.

So the question is did I misconfigure my project so that this is now included for each test file or is this expected for ceedling 1.0.0?

[mvandervoord]

Hi :)

I'm not clear on how it was working previously given your description? In the past, if you were not #includeing mock_platform_mocking.h or platform_mocking.h in the test files, where were the test files picking up function definitions for these functions?

The test files DO need to include all the files that are to be linked, either by using #include or TEST_SOURCE_FILE.

[CJCombrink]

From what I see the test file does not include either one as it does not need platform functions.
Moving to ceedling 1.0.0 I get linker errors,

This is the verbose output

> Shell executed command:
`gcc "build/test/out/<test_folder>/<test_file>.o" "build/test/out/<test_folder>/filter.o" "build/test/out/<test_folder>/<test_file>_runner.o" "build/test/out/<test_folder>/unity.o" "build/test/out/<test_folder>/platform_mocking.o" "build/test/out/<test_folder>/platform_testing.o" -L build/native_all -o "build/test/out/<test_folder>/<test_file>.out" -l<my_lib> -lm`
> With $stdout: <empty>
> With $stderr: 
/usr/bin/ld: build/test/out/<test_folder>/platform_mocking.o:/home/ccombrink/dev/<project>/test/support/platform_mocking.c:8:(.data.rel+0x0): undefined reference to `PLATFORM_MOCK_Log'
/usr/bin/ld: build/test/out/<test_folder>/platform_mocking.o:(.data.rel+0x8): undefined reference to `PLATFORM_MOCK_Print'
/usr/bin/ld: build/test/out/<test_folder>/platform_mocking.o:(.data.rel+0x10): undefined reference to `PLATFORM_MOCK_ZeroedMalloc'
...

The header being compiled is not including platform_mocking.h. For some reason when I add the :paths: -> :support: part to my ceedling 1 project file it is compiled as if it is included.

If I just remove the :support: part from my project file (still ceedling 1.0.0) I get the following, which builds fine

> Shell executed command:
`gcc "build/test/out/<test_folder>/<test_file>.o" "build/test/out/<test_folder>/filter.o" "build/test/out/<test_folder>/<test_file>_runner.o" "build/test/out/<test_folder>/unity.o" -L build/native_all -o "build/test/out/<test_folder>/<test_file>.out" -l<my_lib> -lm`
> With $stdout: <empty>
> With $stderr: <empty>
> And terminated with status: pid 344649 exit 0

note the absence of the "build/test/out/<test_folder>/platform_testing.o" in the second one

[mvandervoord]

Ah. Is PLATFORM_MOCK_Print (for example) defined in the C file or is it fully defined in the header? Is it static? Inline? externed?

[CJCombrink]

Only declared in the header file.
No implementation exists in the source file

platform_mocking.h:

#ifndef <GAURRD_H>
#define <GAURRD_H>

#include <stdarg.h>
#include <stdlib.h>
#include "standards.h"

void PLATFORM_MOCK_Print(const char* fmt, ...);
void *PLATFORM_MOCK_ZeroedMalloc(size_t size);
...

#endif //<GAURRD_H>

[mvandervoord]

Ah, sorry. I wasn't clear. You're showing function declarations in the header (the "footprint" for the function... what arguments it takes and returns, etc). Where does the actual function definition (the implementation) exist?

[CJCombrink]

That is the thing, there is no implementation that I can see, the mock provides it for the ones that includes it in ceedling pre 1.
This is only an issue in ceedling 1.0.0 which is strange for me

[mvandervoord]

I understand your confusion. I'm also confused. If you aren't calling the PLATFORM_MOCK_ functions anywhere in your test files, I'm not sure why it would be looking for them?

It is definitely not the expected behavior... and I'm not able to reproduce it, unfortunately. :(

[jan-joseph]

Hi @mvandervoord ,

I am currently migrating from 0.31.1 to 1.0.1.
I have a similar scenario where I am compiling test_unit C files and Ceedling is considering some C files from :path : support which essentially it shouldn't. i.e. this compilation is throwing undefined errors for data types etc. because of this inclusion, where as in 0.31.1 these C files where not added to the compilation hence everything went correct.

I had a look using -v=debug. and it led to test_invoker.rb

Is it the case that

          compilations       =  []
          compilations       << details[:filepath]
          compilations       += test_core
          compilations       << details[:runner][:output_filepath]
          compilations       += test_frameworks
          compilations       += test_support
          compilations.uniq!

will cause all source files in support to be added to the compilation of the test module regardless of whether it is used or not?

Thanks in advance for your help!

[jan-joseph]

I think I found the problem. Ceedling is trying to create o files for every translation units in the allocated test/support folder.
I tried logging test_objects from test_invoker.rb after line 340 and found that every test modules is added with all .o files from :paths:support:. Could you please confirm if this was the intended behavior @mvandervoord . Thanks!

[mkarlesky]

@jan-joseph @CJCombrink: We discussed all this and came to a few important realizations:

• The use case of :support has lived in ambiguity. The purpose and implementation has actually changed and flip-flopped over time with no clear tracking of it.
• The very first implementation waaaay back was to provide a simple way to compile and link C code that should be part of every test executable. This made it simple for Unity helpers or simulator boot code to be a part of each and every test fixture.
• At some point along the way in the 0.3x lifetime :support became a place to organize code a developer wanted for case-by-case needs in test executables. In fact, all along you could do this with files located in :paths ↳ :test, but it was not well documented (or maybe not documented at all) and was not visible in the command line reports for test paths and files.
• The documentation that persists for :support is thin at best and maybe subtly references its original intent.
• With 1.0.0 we went back to the original implementation without realizing that :support had changed over time and without noting it in breaking changes.

The big takeaway in all this is realizing that both needs — code attached to every test fixture and also selectively included — are real and should be fully supported. Favoring one use case or another for an interpretation of :support is picking a side. So, we have a plan in mind to expand the :support section to easily support both use cases. This will be complemented by some tidying of how test file collections work as well as refining how the various paths: and files: command line reports work.

Please share any questions or reactions.

[jan-joseph]

@mkarlesky Gotit, thanks for the reply! But then I have a general question, is the expected behavior such that all the files in :support to be also included in the coverage report?

[mkarlesky]

@jan-joseph Can you provide a bit more detail on what you mean by coverage report and what you are hoping to see?

[jan-joseph]

I meant the code coverage report generated from gcov.
I do not have a goal per se, just trying to understand how the Code coverage would work when source files are pulled from :support vs :sources. I was under the impression and please correct me here, that if you add files under :support, these files won't considered in the final code coverage report.

[mkarlesky]

Ah. Generally, support is meant for “out of band” code — code not part of your release and code not directly part of your unit tests. This can include test helpers, stubs to stand in for hardware features, boot code for emulator test fixtures, etc. In an “ideal” project all your code would be either source or test with no support code needed.

As the GCov plugin is current arranged, coverage reports are only for your source code (the functions and branches exercised by your unit tests). Users have asked for all code to have coverage reporting. I personally find it noisy and unhelpful to produce reports for test code and especially for mocks, but I can see certain scenarios where that has value. If and when that is added, support code would be included.

Do you have a different need or a different concept of what support code should include?

[jan-joseph]

No, I think your write-up perfectly sums up my use case also. We had a dilemma (mentioned below) when migrating, so just wanted some clarity,

1. when the support files essentially some mock configs and fake middleware code are added in :support, each test case translation unit get compiled with all source files from :support, which was seemingly an overkill and would result in some refactoring in the test case files to get it working with v1.0.1 from v0.31.1
2. If the support files are added in :sources then these fake files are also considered in final code coverage report, which is not ideal but much more "workable" than the first option.