Adrian Crum wrote: > --- On Fri, 3/12/10, Adam Heath <doo...@brainfood.com> wrote: >> Adrian Crum wrote: >>> --- On Fri, 3/12/10, Adam Heath <doo...@brainfood.com> >> wrote: >>>> ah ha! >>>> >>>> This is just excellent. >>>> >>>> Has anyone tried running the test suite right >> now? In >>>> the US? >>>> >>>> The above test fails, because the start date is >> now, but >>>> the end date >>>> is in the future *past* when daylight savings time >> takes >>>> place. So >>>> the interval is off by one hour, and the assertion >> fails. >>>> Does anyone have any ideas about a fix? >>> Does the test code use millisecond arithmetic? If yes, >> then the test fails. Use the TimeDuration class instead, or >> the localized Timestamp adjustment methods in UtilDateTime. >>> Give me a file name and line number. In return I will >> give you more information. >> >> ant run-single-test-suite -Dtest.component=manufacturing >> -Dtest.suiteName=productionruntests >> >> line 260 in >> applications/manufacturing/script/org/ofbiz/manufacturing/test/ProductionRunTests.xml > > There is a flaw in the test code logic. You can't schedule the start and end > of a production run in some point in the past, and then compare that to the > start and end time of some point in the future and then expect them to come > out the same. > > In other words, the demo data is based on a certain elapsed time in the past. > The test creates a new production run based on the same elapsed time, but in > the future. So, the timestamps are going to come out different.
Not completely. The test case worked for ages. Last Friday, it started failing for me. But, then it started working for me again on Saturday, so I didn't think anything of it. Then, tonight, it broken again. This coincides with it jumping the start time by 8 days. It also tells me that the test is fine, and it's the underlying helper code that is broken. Maybe something in quickChangeProductionRunStatus is not doing interval management correctly. > > > >
