In this case: 1. void an obs 2. void the patient 3. unvoid the patient 4. assert that the obs was not unvoided with the patient
Normally this works fine, but this time 1 and 2 happened for the same value of now(), presumably because through the VM I was getting less precision in the clock cycles. So I inserted a Thread.sleep(20) between 1 and 2, and the test passed again. (Thread.sleep(10) wasn't enough...) -Darius On Mon, Sep 12, 2011 at 4:40 PM, Burke Mamlin <[email protected]>wrote: > Agreed. Tests that rely on timing are going to be fragile and/or somewhat > unpredictable. Darius, why does the unit test require a delay? > > -Burke > > On Mon, Sep 12, 2011 at 4:02 PM, Jeremy Keiper <[email protected]> wrote: > >> I really think time-sensitive tests are a bad idea. There must be a way >> to test our time-sensitive code without using delays. If I try to build >> (with tests) on a slow machine, some tests inevitably fail. >> >> Jeremy Keiper >> OpenMRS Core Developer >> AMPATH / IU-Kenya Support >> >> >> >> On Sat, Sep 10, 2011 at 2:11 PM, Darius Jazayeri <[email protected] >> > wrote: >> >>> Yes, we apply the same dateVoided (in milliseconds) to all items >>> recursively deleted in one transaction. >>> >>> Given that we're currently not using voidReason, if you can see an >>> argument for not changing things, I'm happy to leave the code as-is, since >>> adding a delay fixed the unit test. >>> >>> -Darius >>> >>> >>> On Sat, Sep 10, 2011 at 10:39 AM, Burke Mamlin >>> <[email protected]>wrote: >>> >>>> If (1) we are recording the same dateVoided for all data voided in a >>>> single transaction (i.e., even if the voiding takes several seconds) and >>>> (2) >>>> dateVoided is recorded in seconds or milliseconds, then I don't think we >>>> need to require that the voidReason match, since it leaves open the option >>>> to make voidReason appropriate to the object (e.g., we *could* set the >>>> voidReason for obs with "encounter voided" even though the encounter gets a >>>> voidReason of "invalid encounter"). I'm not saying that we need to change >>>> things if we're using the same voidReason across all objects voided in a >>>> single transaction; rather, I'm saying that we don't necessarily need to >>>> *require* the same voidReason across all objects if the voidDate is >>>> unique enough to make the likelihood of duplicate voidDates for the same >>>> patient vanishingly small. >>>> >>>> -Burke >>>> >>>> >>>> On Fri, Sep 9, 2011 at 11:54 PM, Darius Jazayeri >>>> <[email protected]>wrote: >>>> >>>>> FWIW, it looks like the unit test in question is bad, in that it's >>>>> sensitive to the clock time, so putting a Thread.sleep(100) in the middle >>>>> of >>>>> the test fixes it. >>>>> >>>>> But looking at the code I realized that we're not doing things exactly >>>>> right. Currently, when you unvoid a patient, it also unvoids any of their >>>>> encounters and orders with the same voidedBy and dateVoided. But we're not >>>>> looking for the same voidReason. Any reason we shouldn't be looking at >>>>> that >>>>> too? >>>>> >>>>> -Darius >>>>> >>>>> >>>>> On Fri, Sep 9, 2011 at 8:27 PM, Darius Jazayeri >>>>> <[email protected]>wrote: >>>>> >>>>>> So, it looks like the specific problem I was running into is that I >>>>>> was using a workspace folder under one of the parallels-mapped network >>>>>> drives (\\psf\...) and one of Eclipse/Maven/Java/WinXP didn't like that. >>>>>> So >>>>>> after switching to c:\workspace, I was able to get the build to run. >>>>>> >>>>>> Of course then I hit a unit test failure, which happens on this >>>>>> windows VM, but not on the up-to-date checkout I have on my regular OSX >>>>>> install... >>>>>> >>>>>> PatientDataUnvoidHandlerTest >>>>>> org.openmrs.api.handler.PatientDataUnvoidHandlerTest >>>>>> >>>>>> handle_shouldNotUnvoidTheOrdersAndEncountersThatNeverGotVoidedWithThePatient(org.openmrs.api.handler.PatientDataUnvoidHandlerTest) >>>>>> java.lang.AssertionError: >>>>>> at org.junit.Assert.fail(Assert.java:91) >>>>>> at org.junit.Assert.assertTrue(Assert.java:43) >>>>>> at org.junit.Assert.assertTrue(Assert.java:54) >>>>>> at >>>>>> org.openmrs.api.handler.PatientDataUnvoidHandlerTest.handle_shouldNotUnvoidTheOrdersAndEncountersThatNeverGotVoidedWithThePatient(PatientDataUnvoidHandlerTest.java:134) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at >>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>>>> at >>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>>>>> at java.lang.reflect.Method.invoke(Method.java:597) >>>>>> at >>>>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) >>>>>> at >>>>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) >>>>>> at >>>>>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) >>>>>> at >>>>>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) >>>>>> at >>>>>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) >>>>>> at >>>>>> org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) >>>>>> at >>>>>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) >>>>>> at >>>>>> org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82) >>>>>> at >>>>>> org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72) >>>>>> at >>>>>> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240) >>>>>> at >>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) >>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) >>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) >>>>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) >>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) >>>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) >>>>>> at >>>>>> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) >>>>>> at >>>>>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) >>>>>> at >>>>>> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) >>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:236) >>>>>> at >>>>>> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180) >>>>>> at >>>>>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) >>>>>> at >>>>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >>>>>> at >>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) >>>>>> at >>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) >>>>>> at >>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) >>>>>> at >>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) >>>>>> >>>>>> -Darius >>>>>> >>>>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
