XdrIO unit tests #4392
XdrIO unit tests #4392
Conversation
We should be testing other formats this way too
|
MOOSE failure unrelated. Despite the "Inconsistent report tags" problem we don't need the coverage diff here, either; it's going to add approximately 0 lines, since we use Xdr left and right regardless. I still think this is worth the cost to make sure we have no holes in Xdr-for-each-element-type feature coverage, though |
|
Adding No-Optional, No-Unique-ID, and No-XDR recipes, to be safe. |
jwpeterson
left a comment
jwpeterson
left a comment
There was a problem hiding this comment.
Looks good to me, once all the various "No XDR" and "No Optional" recipes are happy.
|
Shoot, I'm trying to register the XDR tests even when we don't have XDR? I though I got the ifdefs right for that. Glad you made me check. |
|
Oh! I got the XDR ifdefs right, but I screwed up the refactoring from the Exodus tests. Should be easy to fix. |
Even if we have ExodusII *and* XDR disabled, we'll still need this base class for XDA tests.
|
Coverage failure is just the "multiple base SHAs" thing. |
|
Final results (at https://civet.inl.gov/pr/26923/) didn't seem to make it to Github, but the only failure is an unrelated MOOSE modules bug. |
|
https://civet.inl.gov/job/3573330/ shows our |
|
https://civet.inl.gov/job/3573770/ seems to have been perfectly happy. Hooray for "unrelated coincidence"! |
3 participants
We did this for ExodusII a while ago, but with the weird behavior we've been seeing from XDR implementations lately it's probably a good idea to get those in testing too, especially since MOOSE (IMHO wisely!) now defaults to XDA/CPA.
I don't like all these gold meshes adding an extra 15% to our tests/ size, but I'm not sure how else to easily get a similar level of safety.