Hello,

Done at rev #1859111

--
Best Regards,
Suraj Khurana
Technical Consultant





On Fri, May 10, 2019 at 11:24 AM Suraj Khurana <[email protected]>
wrote:

> Sure Jacques,
>
> I will get this done by the weekend. Please proceed in case of any blocker
> or urgency. I am also inclined with your thoughts.
> Thanks in advance !!
>
> --
> Best Regards,
> Suraj Khurana
> Technical Consultant
>
> *HotWax Systems Pvt. Ltd*
>
>
>
>
>
> On Thu, May 9, 2019 at 3:17 PM Jacques Le Roux <
> [email protected]> wrote:
>
>> Hi Suraj,
>>
>> Any chances? I don't mind duplicated data as I mentioned answering to
>> Pierre
>>
>> Thanks
>>
>> Jacques
>>
>> Le 27/04/2019 à 15:36, Jacques Le Roux a écrit :
>> > 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
>> >>>>>>>
>> >
>>
>

Reply via email to