6 comments:
Patch Set #1, Line 20: make unit-tests
After cherry-picking the latest patchset, I am able to build and run the unit tests.
Great, thanks!
This commit's purpose is to show basic example of how unit testing may
be applied for coreboot project. It adds test harness for lib/string.c
module.
Show a basic example of how unit testing can be applied for the coreboot project. […]
Done
File tests/include/mocks/assert.h:
Patch Set #1, Line 64: * called.
Sorry, I just wrote these comments in the order I read your code. […]
Done
Patch Set #2, Line 21: string-test-stage:= ramstage
Actually, I'd rather you leave this out so that the reference to others is that you don't need to pr […]
OK.
/* Since strdup() requires malloc() it may only be invoked during ramstage
* phase. Expect dead_code/assert invocation otherwise.
*/
Since unit tests are intended to run on the host, is this comment relevant?
This is actually the excerpt from uut - src/lib/string.c. This is relevant in the sense that I wanted to show example of Cmocka assertion handling (dropped this idea already, see other comments). Actually we have idea of stages now, so this comment is a leftover and I should remove it.
Patch Set #2, Line 34: assert_int_equal(0, memcmp(str, duplicate, strlen(str)));
Cmocka seems to have an assert_string_equal().
Yes, but the trick is that assert_string_equal() is using.. strcmp, which in case of our binary will invoke coreboot implementation. We will actually test unit with unit under test.
At the same time, I'm using strlen() here, but this function is already tested with test_strlen_strings() at this time. One may say that it breaks the idea of test isolation - what do you think? I may change this to constant value, to be on the safe side.
I will add a comment at the top of this file, since this is rather rare case when you shouldn't use functions used "everyday".
To view, visit change 40538. To unsubscribe, or for help writing mail filters, visit settings.