Hi Carsten,

Yes, if parameterized testing were to be introduced then a low-priority
jira should be raised for possibly introducing the same pattern in
FlexibleStringExpanderTests.

It should be a low-priority improvement JIRA since what we currently have
is working well enough for the moment, but someone might have a refactoring
itch they want to scratch!

Thanks,

Dan.

On Mon, 25 May 2020 at 16:48, Carsten Schinzer <
cars...@dcs-verkaufssysteme.de> wrote:

> Sorry, misunderstanding here:
>
> I will try both suggestions from Stackoverflow and decide for one option.
>
> Regarding your suggestion, Dan, I guess that is a new JIRA Improvement
> once I validated the parametrized testing with my test case, right?
>
>
> > Am 25.05.2020 um 17:24 schrieb Carsten Schinzer <
> cars...@dcs-verkaufssysteme.de>:
> >
> > Thanks for the hint, Dan!
> >
> > Also, I just came across this one:
> >
> https://stackoverflow.com/questions/3361239/excluding-a-non-param-test-in-parameterized-test-class
> <
> https://stackoverflow.com/questions/3361239/excluding-a-non-param-test-in-parameterized-test-class
> >
> >
> > I certainly support running each of the parameter sets as an individual
> test, i.e. test counters go up per set executed.
> > I will try both suggestions, the one you suggested and the one from the
> link above.
> >
> > Warm regards
> >
> >
> > Carsten
> >
> >
> >> Am 25.05.2020 um 17:21 schrieb Daniel Watford <d...@foomoo.co.uk
> <mailto:d...@foomoo.co.uk>>:
> >>
> >> Hi Carsten,
> >>
> >> I don't know if there were any reasons historically that precluded use
> of
> >> the parameterized test pattern, but I think it can be quite useful if
> you
> >> are able to make use of it.
> >>
> >> Another test class that could benefit is FlexibleStringExpanderTests
> where
> >> the parameterized test pattern appears to have been implemented without
> >> test library support.
> >>
> >> A benefit of converting FlexibleStringExpanderTests would be that all
> the
> >> various parameterized tests would contribute to the overall test count
> of a
> >> build, rather than being rolled up as part of the public testParsing(),
> >> testWithVerbosity() and testQuietly() methods.
> >>
> >> Thanks,
> >>
> >> Dan.
> >>
> >> On Mon, 25 May 2020 at 15:43, Carsten Schinzer <
> >> cars...@dcs-verkaufssysteme.de <mailto:cars...@dcs-verkaufssysteme.de>>
> wrote:
> >>
> >>> Hello all,
> >>>
> >>>
> >>> I find no other reference to org.junit.Parameterized in the code stack
> on
> >>> trunk which indicates that no-one else has committed parameterized unit
> >>> tests. I am asking because I have a test case where I would need that
> (I
> >>> want to run all options for the CustRequestStatusType against the
> status
> >>> check service an be sure it return the expected result) and when
> >>> implementing I find that my IDE hints that „There is no default
> constructor
> >>> available in class ‚org.apache.ofbiz.service.testtools.OFBizTestCase‘“.
> >>>
> >>>
> >>> package org.apache.ofbiz.order
> >>>
> >>> import org.apache.ofbiz.service.ServiceUtil
> >>> import org.apache.ofbiz.service.testtools.OFBizTestCase
> >>> import org.junit.Test
> >>> import org.junit.runner.RunWith
> >>> import org.junit.runners.Parameterized
> >>> import org.junit.runners.Parameterized.Parameters
> >>>
> >>> @RunWith(Parameterized)
> >>> class CustRequestStatusTests extends OFBizTestCase {
> >>>    private String status
> >>>    private String expect
> >>>    private String scenario
> >>>
> >>>    @Parameters static scenarios() {[
> >>>        ['CRQ_DRAFT',     'PASS', 'CustRequest status Draft expected to
> >>> PASS'],
> >>>        ['CRQ_SUBMITTED', 'PASS', 'CustRequest status Submitted expected
> >>> to PASS'],
> >>>        ['CRQ_ACCEPTED',  'PASS', 'CustRequest status Accepted expected
> to
> >>> PASS'],
> >>>        ['CRQ_REVIEWED',  'PASS', 'CustRequest status Reviewed expected
> to
> >>> PASS'],
> >>>        ['CRQ_PENDING',   'PASS', 'CustRequest status Pending expected
> to
> >>> PASS'],
> >>>        ['CRQ_COMPLETED', 'FAIL', 'CustRequest status Completed expected
> >>> to FAIL'],
> >>>        ['CRQ_REJECTED',  'PASS', 'CustRequest status Rejected expected
> to
> >>> PASS'],
> >>>        ['CRQ_CANCELLED', 'FAIL', 'CustRequest status Cancelled expected
> >>> to FAIL'],
> >>>    ]*.toArray()}
> >>>
> >>>    public CustRequestStatusTests(String name, String status, String
> >>> expect, String scenario) {
> >>>        this.expect   = expect
> >>>        this.scenario = scenario
> >>>        this.status   = status
> >>>        super(name)
> >>>    }
> >>>
> >>>    /* Testing custRequestStatusCheck Service Implementation
> >>>    *
> >>>    * available test data:
> >>>    * (...)
> >>>    *   <CustRequest custRequestId="9000" custRequestDate="2008-07-28
> >>> 09:45:31.928" custRequestTypeId="RF_QUOTE" statusId="CRQ_ACCEPTED"
> >>> fromPartyId="DemoCustomer" priority="9" custRequestName="Customer
> Request
> >>> Usage" description="Demo CustRequest" productStoreId="9000"/>
> >>>    *   <CustRequestItem custRequestId="9000" statusId="CRQ_ACCEPTED"
> >>> custRequestItemSeqId="00001" productId="GZ-1001" story="This can be the
> >>> longer story of an item on the customer request."/>
> >>>    *
> >>>    *  */
> >>>    @Test void testCustRequestStatusCheckEmpty() {
> >>>        Map input = [
> >>>                custRequestId: '9001',
> >>>        ]
> >>>        Map result = dispatcher.runSync('checkStatusCustRequest', input)
> >>>        assert ServiceUtil.isError(result)
> >>>        // assert error message refers to certain text element
> >>>    }
> >>>
> >>>    @Test void testCustRequestStatusCheckWrongStatus() {
> >>>        Map input = [
> >>>                custRequestId: '9000',
> >>>                statusId: this.status,
> >>>        ]
> >>>        Map result = dispatcher.runSync('checkStatusCustRequest', input)
> >>>        if(this.expect == 'PASS') {
> >>>            assert ServiceUtil.isSuccess(result)
> >>>        } else {
> >>>            assert ServiceUtil.isFailure(result)
> >>>        }
> >>>    }
> >>> }
> >>>
> >>>
> >>>
> >>> This hint certainly has to do with the implementation I need to do for
> >>> such test cases using annotations to mark the class as @Parameterized,
> >>> define the @Parameters and then mark the @Test that uses the
> parameters.
> >>>
> >>> Before I dive too much into web search:
> >>> - has anyone attempted this for OFBiz unit Testing? (And hence the
> reason
> >>> why no implementation is avail)
> >>>
> >>> Thanks for a hint :)
> >>> Warm regards
> >>>
> >>>
> >>> Carsten
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> Daniel Watford
> >
>
>

-- 
Daniel Watford

Reply via email to