Hi Jacques, all, Currently, we can't avoid having duplicates in test data when we load such data just before the execution a test-suite/test-case. We should not concern ourselves to much with this. After all it is just data for test, and reloading a few duplicates should not be regarded as a major issue.
However, if the community is adamantly set on removing such duplicates, then it should work on having test-data being loaded before any and all test-suites/test-cases gets executed. IMO this involves moving test-data from within the testdef folder (like in the order component) to the data folder of the component and having a separate loadTestData task. Best regards, Pierre Smits *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges) since 2008* Apache Steve <https://steve.apache.org>, committer On Sat, Apr 27, 2019 at 3:38 PM Jacques Le Roux < [email protected]> wrote: > Thanks Suraj, > > Can't we avoid the duplicated data? > > Jacques > > Le 27/04/2019 à 15:17, Suraj Khurana a écrit : > > Hello team, > > > > I have checked and found that there is a data dependency of > > workEffortId=9000 in the test case which is available in > plugins/projectmgr > > component. > > > > This was the main reason testIntegration was failing without having > plugins > > component. I will take care of it and add respective dependent data on > > order test data file. > > > > I think its making sense now and we don't need to revert now. > > > > -- > > Best Regards, > > Suraj Khurana > > > > > > > > > > > > > > On Sat, Apr 27, 2019 at 10:14 AM Suraj Khurana <[email protected]> > > wrote: > > > >> Sure Jacques, > >> > >> I am into it today and if got nothing I will remove OrderTests.groovy > >> > >> -- > >> Best Regards, > >> Suraj Khurana > >> > >> > >> > >> > >> > >> > >> > >> On Fri, Apr 26, 2019 at 7:27 PM Jacques Le Roux < > >> [email protected]> wrote: > >> > >>> Hi Suraj, > >>> > >>> I think that, as suggested by Mathieu, in the meantime it's better to > >>> remove “OrderTests.groovy” > >>> > >>> Because it could hide other issues else reported by Buildbot which is > our > >>> last safeguard > >>> > >>> Thanks > >>> > >>> Jacques > >>> > >>> Le 25/04/2019 à 10:52, Pierre Smits a écrit : > >>>> Hi Mathieu, > >>>> > >>>> Is there a way to move this forward? > >>>> > >>>> Best regards, > >>>> > >>>> Pierre Smits > >>>> > >>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President* > >>>> *Apache Directory <https://directory.apache.org>, PMC Member* > >>>> Apache Incubator <https://incubator.apache.org>, committer > >>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without > >>> privileges) > >>>> since 2008* > >>>> Apache Steve <https://steve.apache.org>, committer > >>>> > >>>> > >>>> On Sat, Apr 20, 2019 at 2:25 PM Pierre Smits <[email protected]> > >>> wrote: > >>>>> Maybe we should move the load aspects regarding tests out of the test > >>>>> suite invocations altogether. > >>>>> The gradlew tasks states: > >>>>> > >>>>> task testIntegration(group: ofbizServer) { > >>>>> > >>>>> dependsOn 'ofbiz --test' > >>>>> > >>>>> description 'Run OFBiz integration tests; You must run loadAll before > >>>>> running this task' > >>>>> > >>>>> } > >>>>> > >>>>> > >>>>> IMO, loading test data could be part of the loadAll task. > >>>>> > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Pierre Smits > >>>>> > >>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President* > >>>>> *Apache Directory <https://directory.apache.org>, PMC Member* > >>>>> Apache Incubator <https://incubator.apache.org>, committer > >>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without > >>> privileges) > >>>>> since 2008* > >>>>> Apache Steve <https://steve.apache.org>, committer > >>>>> > >>>>> > >>>>> On Sat, Apr 20, 2019 at 1:56 PM Mathieu Lirzin < > >>> [email protected]> > >>>>> wrote: > >>>>> > >>>>>> Pierre Smits <[email protected]> writes: > >>>>>> > >>>>>>> I believe there are a few more where testing individual test-suites > >>>>>> and/or > >>>>>>> test-cases are dependent on data loaded in other test-suites and/or > >>>>>> other > >>>>>>> test-cases. > >>>>>> I have the same experience. Moreover another source of fragility is > >>>>>> that tests depend on other tests within a single OFBiz “test-case”, > >>>>>> meaning one test can depend on the data produced by another test. > >>> This > >>>>>> is acceptable for a “simple-method-test” because the order of > >>> execution > >>>>>> is sequential and managed by OFBiz, but this is problematic for > JUnit > >>>>>> tests (Groovy, Java) because the order while being deterministic > >>> depends > >>>>>> on the arbitrary order imposed by the JVM. > >>>>>> > >>>>>> For example I know for a fact that “QuoteTests.groovy” is suffering > >>> from > >>>>>> that issue. > >>>>>> > >>>>>>> While I don't hear/read about failing testIntegration (except where > >>>>>> code in > >>>>>>> the base is faulty, not when test-suites/cases are faulty), I see > >>>>>> following > >>>>>>> failures in test executions in OFBiz against jdk11: > >>>>>>> > >>>>>>> > >>>>>>> 1. Execution failed for task ':ofbiz --test component=webapp > >>> --test > >>>>>>> suitename=webapptests'. > >>>>>>> 2. Execution failed for task ':ofbiz --test > component=accounting > >>>>>> --test > >>>>>>> suitename=invoicetest'. > >>>>>>> 3. Execution failed for task ':ofbiz --test component=order > >>> --test > >>>>>>> suitename=ordertests'. > >>>>>>> 4. Execution failed for task ':ofbiz --test component=product > >>> --test > >>>>>>> suitename=producttests'. > >>>>>>> > >>>>>>> Do we have these test failing also when doing the test execution > >>> against > >>>>>>> jdk8? > >>>>>>> *Caveat: I recently set this up, so there may still be some > >>>>>> configuration > >>>>>>> issues in the jdk11-test setup.. * > >>>>>> I have just tested the “ordertests” test-suite with Icedtea 3.7 > >>> (jdk-8) > >>>>>> and it is still failing, so it seems unrelated in that case. > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> -- > >>>>>> Mathieu Lirzin > >>>>>> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 > >>>>>> >
