Unity runs only one test case (from two) on the target (Arduino Mega 2560).
That leads to a wrong summary “passed” when the latter testcase had passed, but the other had failed.
When compiled and run under the “native” environment, both cases are executed and show passed / fail correctly.
Could you please show us your complete test code - not only the part for the native environment. Without that it’s hard to say where the problem comes from …
Hi, this was the complete test code, except setUp() and tearDown(). Basically only the boilerplate code that “tests” these two testcases.
Meanwhile, I have extended it to more testcases, and I vary the tests activated in main(). Sometimes, it runs all of them, sometimes only the last one, sometimes only one but this one twice ! Sometimes, it correcly shows the overall “failed”, sometimes it shows “succeed” even when one (not run) testcase should fail.
I cannot see a pattern here, but it seems like a parsing problem.
This setup here runs only test4, and shows “succeeded”, although test3 should fail:
It evaluates the list of RUN_TEST macros, since when I comment single testcases out (or in), the result changes, too. Thus, it does not seem like a refresh issue.
Since it works perfectly on the native platform, but not on the target, I assume that is something with the different toolchain or the macro implementation on the other platform.
The macro is in \.pio\libdeps\megaatmega2560\unity_internals.h; wheras the implementation for native and Mega2560 is the same. So maybe it is an 8-bit vs. 64-bit issue.
all tests are actually executed once. (I have introduced a global counter which is incremented by each testcase, and let that be the “failed” result of the last one to be displayed.)
Furthermore, I noticed that the result varys when I UnityPrint() something before each RUN_TEST or directly in UnityDefaultTestRun() in unity.c. Depending on the length of that additional text (between 5 and 6 characters), it worked or not. First I thought of kind of a memory issue…
These were the clues that this might actually be a timing problem in a way that the interface that communicates results back to platformio’s test runner is not yet properly initialized, so that the test runner does not get all results or reads from a corrupted buffer (therefore the wrong displayed number of tests, or some outdated content that is read again).
Introducing a little delay before the test run does the job, however requires that the original Arduino main() is used, therefore a small switch between native and target environments:
You are right. Now as you write it, I see it in the other examples and issue reports. Seems that I have picked exactly that tutorial that did not mention the timing aspect with the target hardware.
Never mind, I have learned a lot about unity and its internals (by scanning its code). That’s how we learn - sometimes.
Thanks anyway for answering!