runit_NOPASS_demo_exec2.R: java.lang.AssertionError: unexpected pending count, expected 1, got 3 at hex.glm.GLM$GLMLambdaTask$LineSearchIteration.callback(GLM.java:529)
Maybe that's the first step, is to see if all NOPASS r tests have a jira
I assume they don't
This goes to my question of gauging doneness. i think test writers know that certain features aren't in yet, and maybe a NOPASS test exposes that,
but there's not an expectation that test writers are somehow riding herd on project management..i.e. responsible for documenting all "work not yet done'
I filed a jira on this
I think it overlaps with an existing jira that gets the same
It's reasonable to say that the JIRA next step, should be to modify the test to not be intermittent
It should have a ticket whether or not it's intermittent.
Please fill in the test case field.
On Mar 6, 2015 5:10 PM, "Kevin" <firstname.lastname@example.org> wrote:
there are numerous GLM tests that get these intermittent failures, that I changed to NOPASS, and they're being changed from NOPASS, with no underlying change to GLM, so they just fail again intermittently, and I change them back to NOPASS.
Maybe the problem is there's no jira filed on these?
If the test is intermittent, it probably needs modification to only run the case that fails, multiple times. Or with a fixed seed that matches the failure. Then it's not intermittent and can be a jira
True fail list: runit_demo_exec2.R
barrier onExCompletion for hex.glm.GLM$1@76a4120d
java.lang.AssertionError: unexpected pending count, expected 1, got 3