[opensource-dev] Crashing integration tests (was: (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!))

Boroondas Gupte sllists at boroon.dasgupta.ch
Mon Oct 25 12:56:29 PDT 2010


 On 10/25/2010 04:01 PM, Boroondas Gupte wrote:
> Also, when tests are enabled, one of them errors out. That's right,
> it's *not even failing*. :-P
>
>     Running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage
>     Unit test group_started name=llsdmessage
>     Failed to catch N11LLEventPump11DupPumpNameE
>     Failure running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage
>     Error: 245
>     make[2]: *** [llmessage/INTEGRATION_TEST_llsdmessage] Error 245
>     make[1]: *** [llmessage/CMakeFiles/INTEGRATION_TEST_llsdmessage.dir/all] Error 2
>     make: *** [all] Error 2
>
> Wolfpup observed that INTEGRATION_TEST_llcapabilitylistener also has
> runtime issues.

What is interesting ---and honestly a bit frightening--- is that on
Linux with GNU make you don't have to disable the integration tests with
-DLL_TESTS=OFF or set them up to be skipped in the test's source with
skip("...") to work around these build-stoppers. If you just re-issue
make again (without cleaning first), it'll *continue the build without
re-trying the test* that just before not-even-failed.

While incremental builds are a great thing, and tests don't need to be
re-run when they've /previously succeeded/ and none of their
dependencies nor the test itself changed since, I guess this isn't how
tests are supposed to work. If a test /fails/ or even /causes a runtime
error/, it should not be skipped until explicitly disabled, either by
LL_TESTS or in the test's source. How else would you know whether you've
fixed the issue?


        User story

As a developer, I want to be sure the build doesn't (seem to) succeed
when I've broken a test I didn't disable. (At least as long as I haven't
tampered with dependency declarations or the build system.)

Boroondas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101025/39061cd2/attachment.htm 


More information about the opensource-dev mailing list