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 > _________________________________________ 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]
