From: Branden A. <b.m...@gm...> - 2020-09-06 15:17:34
|
>From seeing this in your output: 100%: Checks: 29, Failures: 0, Errors: 0 It seems your tests did run, all 29 of them. And they all passed. Also, your unit tests covered 91% of your source lines. Your concern is that there are no code coverage metrics for the unit tests, right? Typically the code coverage instrumentation is for the source code and not the tests themselves. I dont think it's necessary to check the code coverage of the unit tests. Maybe change the gcovr command to check only the files under your src directory. > Does having a --disable-timeout-tests means that I can't use check normally? That only affects what tests Check runs on itself. It will not change the behavior of Check. > Is there any way to fix my "CPU constrained" system? If you are not using Check's test timeout functionality in your unit tests for your project I'd not worry about the timeout tests. It appears that your tests are passing. On Sat, Sep 5, 2020 at 8:02 PM Billy Julius <bil...@gm...> wrote: > Hi Branden, thanks for the response. > > Firstly, yes I need the latest version of check. I tried with the sudo > apt-get install check, but it doesn't work on my homework project. I asked > my friend whose check is able to work and he said that I need the latest > one. > > I just did the ./configure --disable-timeout-tests, and the other tests > went fine, no errors for check_check_export and check_check. So I tried > sudo make install, then I go and do "make all" command on my homework > project, yet the file check_point.c in the tests folder was not executed at > all, with details as the following : > > gcc point.o check_point.o -lcheck -lm -lpthread -lrt -lgcov -coverage -o > check_point_tests > ./check_point_tests > libgcov profiling error:/home/null/Desktop/Billy > Julius/Point/check_point.gcda:Version mismatch - expected 10.0 > (experimental) (B00e) got 10.2 (release) (B02*) > Running suite(s): Point > 100%: Checks: 29, Failures: 0, Errors: 0 > gcovr -s -d > > ------------------------------------------------------------------------------ > GCC Code Coverage Report > Directory: . > > ------------------------------------------------------------------------------ > File Lines Exec Cover Missing > > ------------------------------------------------------------------------------ > src/point.c 74 68 91% > 26,39-41,44,55 > tests/check_point.c 222 0 0% > 8,12-15,17,21,23-24,26-28,31,33-34,36-38,41,43-44,46-48,51,53-54,56-58,61,63,65-67,70,72,74-76,79,81,83-85,88,90,92-94,97,99,101-103,106,108,110-112,115,117,119-121,124,126,128-130,133,135,137-139,142,144,146-148,151,153,155-157,160,162-164,166-169,172,174-176,178-181,184,186-188,190-192,194-197,200,203-204,206-208,211,214-215,217-219,222,224-225,227-228,231,233-235,237-238,241,243-244,246-248,251,253-254,256-258,261,263-264,266-268,271,273-274,276-278,281,283-284,286-288,291,293,295-296,298-299,301-303,306,310,312-314,316-321,323-335,337-351,353,356-357,361-362,364-367 > > ------------------------------------------------------------------------------ > TOTAL 296 68 23% > > ------------------------------------------------------------------------------ > lines: 23.0% (68 out of 296) > branches: 21.2% (28 out of 132) > > Does having a --disable-timeout-tests means that I can't use check > normally? Is there any way to fix my "CPU constrained" system? > > Thank You. > > On Sun, 6 Sep 2020, 05:16 Branden Archer, <b.m...@gm...> wrote: > >> For Ubuntu you should be able to install libcheck using the following >> instructions: >> >> https://libcheck.github.io/check/web/install.html#aptitude >> >> That way you will not need to rebuild Check, unless you want a newer >> version than Ubuntu provides. >> >> Looking at the logs I see failures around timeout tests. For example, >> this test >> >> >> https://github.com/libcheck/check/blob/c94962c5ed3120291557e978fa523780a802ac93/tests/check_check_sub.c#L2650 >> >> should take longer than 9 seconds to run, and is configured to fail if it >> runs longer than 6 seconds: >> >> >> https://github.com/libcheck/check/blob/c94962c5ed3120291557e978fa523780a802ac93/tests/check_check_sub.c#L3242 >> >> This test confirms that Check is able to detect when tests take too long >> to run and properly time them out. The provided test logs show that instead >> of timing the test out it said the test passed: >> >> check_check_master.c:683:F:Core Tests:test_check_all_msgs:226: For test >> 226:Timeout Integer Scaling Tests:test_sleep9_fail expected 'Test timeout >> expired', got 'Passed' >> >> I'm not sure why that would be. I've seen behavior like this on some >> systems that are very CPU constrained, such as when many VMs are running >> when the tests are also running. >> >> These tests are not as deterministic as the others, as they assume some >> behaviors of the OSs CPU scheduler. If you would like to skip them and see >> if the rest of the tests pass, try this >> <https://github.com/libcheck/check/blob/master/configure.ac#L66>: >> >> ./configure --disable-timeout-tests >> make >> make check >> >> >> - Branden >> >> >>> >>> ---------- Forwarded message ---------- >>> From: Billy Julius <bil...@gm...> >>> To: che...@li... >>> Cc: >>> Bcc: >>> Date: Sat, 5 Sep 2020 13:04:19 +0700 >>> Subject: check_check_export and check_check fails when make check command >>> Hello, I'm Billy >>> >>> I just tried installing check to my PC but I encountered a problem. So >>> after I downloaded the latest check source from >>> https://github.com/libcheck/check/releases, I used Ubuntu and move to >>> the unpacked directory, run these following commands : >>> ./configure >>> make >>> make check >>> >>> The make check step fails, with details test_suite.log attached. >>> Is there anything wrong with my PC and anything to solve this problem? >>> >>> Thank You. >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: che...@li... >>> To: >>> Cc: >>> Bcc: >>> Date: Sat, 05 Sep 2020 06:04:51 +0000 >>> Subject: confirm ce2627daf3ad4d37dcda3cd36b2e6b20a754d2aa >>> If you reply to this message, keeping the Subject: header intact, >>> Mailman will discard the held message. Do this if the message is >>> spam. If you reply to this message and include an Approved: header >>> with the list password in it, the message will be approved for posting >>> to the list. The Approved: header can also appear in the first line >>> of the body of the reply. >> >> |