Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/39893 )
Change subject: Documentation: Add proposal for firmware unit testing ......................................................................
Patch Set 1:
(2 comments)
https://review.coreboot.org/c/coreboot/+/39893/1/Documentation/technotes/202... File Documentation/technotes/2020-03-unit-testing-coreboot.md:
https://review.coreboot.org/c/coreboot/+/39893/1/Documentation/technotes/202... PS1, Line 190: Cmocka also include support : for mocks.
Yes, this makes sense. We need to combine preprocessor and linker tricks in order to do this. […]
Well, I think once you have unit tests there's always some work to keep them in sync when the tested code changes. I think that's normal and this shouldn't be any different.
I understand that this would be an "advanced" feature for later, just wanna point out these things I can think of so we keep them in mind when deciding on the basic design. Doesn't mean they need to be supported in the first version.
https://review.coreboot.org/c/coreboot/+/39893/1/Documentation/technotes/202... PS1, Line 232: prefix
My point with object files' names is that I don't want to mimic directory structure under /build since I want to avoid confusion between products of normal coreboot build and unit test build of particular module.
Do you mean you don't want to have subdirectories under build/tests (so the test binary would be build/tests/gpio-test, not build/tests/lib/gpio-test)? No, you can't do that, not if you want test names to directly map to source file names. Like I said, there are hundreds of cases in coreboot where two source files in different directories have the same name (e.g. src/lib/gpio.c and src/soc/rockchip/common/gpio.c), you cannot expect source file names to be globally distinct. The normal coreboot build system also builds a subdirectory hierarchy under build/ that mirrors the one under src/ (e.g. the object for src/lib/gpio.c is build/<stage>/lib/gpio.o).