Re: [lmi] Running unit tests in less time

[Greg Chicares]

On 2017-01-06 15:27, Greg Chicares wrote:
> See commit a905d1969eac34f599c7b6ef4f3856a606d33be1 .

Parallelism does have its drawbacks...

> In one trial, I saw:
> 
> Running premium_tax_test:
> 
> ** uncaught exception: std::runtime_error: Unable to parse xml file 
> 'Z:/opt/lmi/src/build/lmi/Linux/gcc/ship/sample.policy': Document is empty
> [file /opt/lmi/src/lmi/xml_lmi.cpp, line 69]
> 
> which would seem to be the problem discussed here:
> 
> http://lists.nongnu.org/archive/html/lmi/2014-10/msg00018.html
> http://lists.nongnu.org/archive/html/lmi/2014-10/msg00019.html
> 
> I hadn't seen it again until today. I speculate that it might occur
> only the first time the unit tests are run after 'make clean', which
> would mean that it's not a high enough priority to fix right now,
> unless it keeps arising.

It keeps arising, and I haven't done 'make clean' in the interim
so that's not the cause.

http://lists.nongnu.org/archive/html/lmi/2017-01/msg00038.html
| Running product_file_test:
|
| ** uncaught exception: std::runtime_error: Unable to parse xml file 
| 'Z:/opt/lmi/src/build/lmi/Linux/gcc/ship/sample.policy': Document is empty
| [file /opt/lmi/src/lmi/xml_lmi.cpp, line 69]

And just now I got this:

Running mc_enum_test:

** uncaught exception: std::exception: boost::filesystem::is_directory: 
"Z:\opt\lmi\src\build\lmi\Linux\gcc\ship\eraseme.ndx": File not found.

**** returning with error code 200
**********  errors detected; see stdout for details  ***********
/opt/lmi/src/lmi/workhorse.make:1141: recipe for target 'mc_enum_test.exe-run' 
failed

That seems puzzling: 'mc_enum_test' shouldn't be looking for any
rate_table database. (Product database, yes, because it tests
'ce_product_name'; but rate_table database, no.) But the snippet
quoted begins with
  Running mc_enum_test:
and ends with
  recipe for target 'mc_enum_test.exe-run' failed
and this is the only test that failed, so this can't be a defect
in the way 'make' groups output with '--output-sync=recurse'.

The only reasonable hypothesis I have is that some of these unit
tests write files that others use, so that collisions arise when
they're run in parallel. But I don't see how this latest error can
occur at all.

At least it does vanish if I rerun the unit-test suite, so it's
not a reproducible error caused by my pending static_assert changes,
which I can therefore commit and push now.