You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Mathieu Lirzin <ma...@nereide.fr> on 2019/10/07 11:49:59 UTC
Providing utilitaries for integration tests (was: svn commit: r1867889 …)
Hello Jacques,
Jacques Le Roux <ja...@les7arts.com> writes:
> I had a look at this idea but I finally gave up. I thought about creating
>
> public static Map testGroovy(Map<String, String> paramNames, String serviceName) {
> userLogin = EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 'system').cache().queryOne()
> Map serviceCtx = paramNames.put("userLogin", EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 'system').cache().queryOne())
> Map result = dispatcher.runSync(serviceName, serviceCtx)
> }
>
> And only pass params and service name, but EntityQuery is not yet available in base component when compiling.
What do you mean by “EntityQuery is not yet available in base component
when compiling”?
Can you provide a patch and the command you run to get to this failing
scenario?
> Anyway it would add much, just a cover function
>
> Le 03/10/2019 à 14:29, Jacques Le Roux a écrit :
>> BTW looking at OrderTests.groovy it seems we can refactor Groovy tests, a lot of is common...
>>
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Providing utilities for integration tests
Posted by Jacques Le Roux <ja...@les7arts.com>.
e 13/10/2019 à 14:08, Mathieu Lirzin a écrit :
> Le 08/10/2019 à 13:12, Jacques Le Roux a écrit :
>>> Hi Mathieu
>>>
>>> I forgot to mention that I put this method in GroovyUtil.java.
>>>
>>> It was hastily done because doing so I rapidly thought that "Anyway it would not add much, just a cover function"
>>>
>>> It works with a complete/correct version:
>>>
>>> public static Map testGroovy(Delegator delegator, LocalDispatcher dispatcher, Map<String, Object> serviceCtx,
>>> String serviceName) throws GenericEntityException, GenericServiceException {
>>> GenericValue userLogin = EntityQuery.use(delegator)
>>> .from("UserLogin")
>>> .where("userLoginId", "system")
>>> .cache()
>>> .queryOne();
>>> serviceCtx.put("userLogin", userLogin);
>>> return dispatcher.runSync(serviceName, serviceCtx);
>>> }
>>>
>>> I still wonder if it of much use, ie compare:
>>>
>>> void testSendOrderChangeNotification() {
>>> Map serviceCtx = [
>>> orderId: 'TEST_DEMO10090',
>>> sendTo: 'test_email@example.com',
>>> ]
>>> Map serviceResult = GroovyUtil.testGroovy(delegator, dispatcher, serviceCtx, 'sendOrderChangeNotification');
>>> assert ServiceUtil.isSuccess(serviceResult)
>>> assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
>>> }
>>>
>>> with
>>>
>>> void testSendOrderChangeNotification() {
>>> Map serviceCtx = [
>>> orderId: 'TEST_DEMO10090',
>>> sendTo: 'test_email@example.com',
>>> userLogin: EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 'system').cache().queryOne()
>>> ]
>>> Map serviceResult = dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
>>> assert ServiceUtil.isSuccess(serviceResult)
>>> assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
>>> }
>>>
>>> It's shorter and can be used for most Groovy tests. But you have to
>>> pass the delegator, dispatcher and serviceCtx which are else
>>> transparent. Not sure it's of better use.
>>>
>>> What do you think?
> I agree that that having to pass the delegator, dispatcher and
> serviceCtx is not ideal and tend make the test less clear.
>
> In order to avoid repetitive code a nice first helper method would be
> for example one for retrieving the default userLogin like what is done
> in ‘QuoteTests.groovy’
>
> // Retrieves a particular login record.
> GenericValue getUserLogin(String userLoginId) {
> GenericValue userLogin = EntityQuery.use(delegator)
> .from('UserLogin').where(userLoginId: userLoginId).queryOne()
> assert userLogin
> return userLogin
> }
>
> We could even add a default login user.
>
> // Retrieves the default login record.
> GenericValue getUserLogin() {
> return getUserLogin('system');
> }
>
> I guess we should add such method directly in the ‘OFBizTestCase’ class
> to be able to reuse it in all test cases and avoid having to pass the
> ‘delegator’ and ‘dispatcher’ as method arguments.
>
> The creation of the service input map of your example would look like
> this:
>
> void testSendOrderChangeNotification() {
> Map serviceCtx = [
> orderId: 'TEST_DEMO10090',
> sendTo: 'test_email@example.com',
> userLogin: getUserLogin()
> ]
> Map serviceResult = dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
> assert ServiceUtil.isSuccess(serviceResult)
> assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
> }
>
> In any case I think that finding the generic and reusable helper methods
> can be done incrementally.
>
> What do you think?
Thanks Mathieu,
That sounds like a good idea to me. I have created OFBIZ-11247 for that
Jacques
Re: Providing utilitaries for integration tests
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Hello Jacques,
Jacques Le Roux <ja...@les7arts.com> writes:
> So we give up here, right?
I think providing helper methods for integration tests is a good long
term idea, So I don't think we should give up. :-)
> Le 08/10/2019 à 13:12, Jacques Le Roux a écrit :
>
>> Hi Mathieu
>>
>> I forgot to mention that I put this method in GroovyUtil.java.
>>
>> It was hastily done because doing so I rapidly thought that "Anyway it would not add much, just a cover function"
>>
>> It works with a complete/correct version:
>>
>> public static Map testGroovy(Delegator delegator, LocalDispatcher dispatcher, Map<String, Object> serviceCtx,
>> String serviceName) throws GenericEntityException, GenericServiceException {
>> GenericValue userLogin = EntityQuery.use(delegator)
>> .from("UserLogin")
>> .where("userLoginId", "system")
>> .cache()
>> .queryOne();
>> serviceCtx.put("userLogin", userLogin);
>> return dispatcher.runSync(serviceName, serviceCtx);
>> }
>>
>> I still wonder if it of much use, ie compare:
>>
>> void testSendOrderChangeNotification() {
>> Map serviceCtx = [
>> orderId: 'TEST_DEMO10090',
>> sendTo: 'test_email@example.com',
>> ]
>> Map serviceResult = GroovyUtil.testGroovy(delegator, dispatcher, serviceCtx, 'sendOrderChangeNotification');
>> assert ServiceUtil.isSuccess(serviceResult)
>> assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
>> }
>>
>> with
>>
>> void testSendOrderChangeNotification() {
>> Map serviceCtx = [
>> orderId: 'TEST_DEMO10090',
>> sendTo: 'test_email@example.com',
>> userLogin: EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 'system').cache().queryOne()
>> ]
>> Map serviceResult = dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
>> assert ServiceUtil.isSuccess(serviceResult)
>> assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
>> }
>>
>> It's shorter and can be used for most Groovy tests. But you have to
>> pass the delegator, dispatcher and serviceCtx which are else
>> transparent. Not sure it's of better use.
>>
>> What do you think?
I agree that that having to pass the delegator, dispatcher and
serviceCtx is not ideal and tend make the test less clear.
In order to avoid repetitive code a nice first helper method would be
for example one for retrieving the default userLogin like what is done
in ‘QuoteTests.groovy’
// Retrieves a particular login record.
GenericValue getUserLogin(String userLoginId) {
GenericValue userLogin = EntityQuery.use(delegator)
.from('UserLogin').where(userLoginId: userLoginId).queryOne()
assert userLogin
return userLogin
}
We could even add a default login user.
// Retrieves the default login record.
GenericValue getUserLogin() {
return getUserLogin('system');
}
I guess we should add such method directly in the ‘OFBizTestCase’ class
to be able to reuse it in all test cases and avoid having to pass the
‘delegator’ and ‘dispatcher’ as method arguments.
The creation of the service input map of your example would look like
this:
void testSendOrderChangeNotification() {
Map serviceCtx = [
orderId: 'TEST_DEMO10090',
sendTo: 'test_email@example.com',
userLogin: getUserLogin()
]
Map serviceResult = dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
assert ServiceUtil.isSuccess(serviceResult)
assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
}
In any case I think that finding the generic and reusable helper methods
can be done incrementally.
What do you think?
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Providing utilitaries for integration tests
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Mathieu,
So we give up here, right?
Jacques
Le 08/10/2019 à 13:12, Jacques Le Roux a écrit :
> Hi Mathieu
>
> I forgot to mention that I put this method in GroovyUtil.java.
>
> It was hastily done because doing so I rapidly thought that "Anyway it would not add much, just a cover function"
>
> It works with a complete/correct version:
>
> public static Map testGroovy(Delegator delegator, LocalDispatcher dispatcher, Map<String, Object> serviceCtx,
> String serviceName) throws GenericEntityException, GenericServiceException {
> GenericValue userLogin = EntityQuery.use(delegator)
> .from("UserLogin")
> .where("userLoginId", "system")
> .cache()
> .queryOne();
> serviceCtx.put("userLogin", userLogin);
> return dispatcher.runSync(serviceName, serviceCtx);
> }
>
> I still wonder if it of much use, ie compare:
>
> void testSendOrderChangeNotification() {
> Map serviceCtx = [
> orderId: 'TEST_DEMO10090',
> sendTo: 'test_email@example.com',
> ]
> Map serviceResult = GroovyUtil.testGroovy(delegator, dispatcher, serviceCtx, 'sendOrderChangeNotification');
> assert ServiceUtil.isSuccess(serviceResult)
> assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
> }
>
> with
>
> void testSendOrderChangeNotification() {
> Map serviceCtx = [
> orderId: 'TEST_DEMO10090',
> sendTo: 'test_email@example.com',
> userLogin: EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 'system').cache().queryOne()
> ]
> Map serviceResult = dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
> assert ServiceUtil.isSuccess(serviceResult)
> assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
> }
>
> It's shorter and can be used for most Groovy tests. But you have to pass the delegator, dispatcher and serviceCtx which are else transparent. Not
> sure it's of better use.
>
> What do you think?
>
> Jacques
>
> Le 07/10/2019 à 13:49, Mathieu Lirzin a écrit :
>> Hello Jacques,
>>
>> Jacques Le Roux <ja...@les7arts.com> writes:
>>
>>> I had a look at this idea but I finally gave up. I thought about creating
>>>
>>> public static Map testGroovy(Map<String, String> paramNames, String serviceName) {
>>> userLogin = EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 'system').cache().queryOne()
>>> Map serviceCtx = paramNames.put("userLogin", EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 'system').cache().queryOne())
>>> Map result = dispatcher.runSync(serviceName, serviceCtx)
>>> }
>>>
>>> And only pass params and service name, but EntityQuery is not yet available in base component when compiling.
>> What do you mean by “EntityQuery is not yet available in base component
>> when compiling”?
>>
>> Can you provide a patch and the command you run to get to this failing
>> scenario?
>>
>>> Anyway it would add much, just a cover function
>>>
>>> Le 03/10/2019 à 14:29, Jacques Le Roux a écrit :
>>>> BTW looking at OrderTests.groovy it seems we can refactor Groovy tests, a lot of is common...
>>>>
>> --
>> Jacques Le Roux
Re: Providing utilitaries for integration tests
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Mathieu
I forgot to mention that I put this method in GroovyUtil.java.
It was hastily done because doing so I rapidly thought that "Anyway it would not add much, just a cover function"
It works with a complete/correct version:
public static Map testGroovy(Delegator delegator, LocalDispatcher dispatcher, Map<String, Object> serviceCtx,
String serviceName) throws GenericEntityException, GenericServiceException {
GenericValue userLogin = EntityQuery.use(delegator)
.from("UserLogin")
.where("userLoginId", "system")
.cache()
.queryOne();
serviceCtx.put("userLogin", userLogin);
return dispatcher.runSync(serviceName, serviceCtx);
}
I still wonder if it of much use, ie compare:
void testSendOrderChangeNotification() {
Map serviceCtx = [
orderId: 'TEST_DEMO10090',
sendTo: 'test_email@example.com',
]
Map serviceResult = GroovyUtil.testGroovy(delegator, dispatcher, serviceCtx, 'sendOrderChangeNotification');
assert ServiceUtil.isSuccess(serviceResult)
assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
}
with
void testSendOrderChangeNotification() {
Map serviceCtx = [
orderId: 'TEST_DEMO10090',
sendTo: 'test_email@example.com',
userLogin: EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 'system').cache().queryOne()
]
Map serviceResult = dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
assert ServiceUtil.isSuccess(serviceResult)
assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
}
It's shorter and can be used for most Groovy tests. But you have to pass the delegator, dispatcher and serviceCtx which are else transparent. Not sure
it's of better use.
What do you think?
Jacques
Le 07/10/2019 à 13:49, Mathieu Lirzin a écrit :
> Hello Jacques,
>
> Jacques Le Roux <ja...@les7arts.com> writes:
>
>> I had a look at this idea but I finally gave up. I thought about creating
>>
>> public static Map testGroovy(Map<String, String> paramNames, String serviceName) {
>> userLogin = EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 'system').cache().queryOne()
>> Map serviceCtx = paramNames.put("userLogin", EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 'system').cache().queryOne())
>> Map result = dispatcher.runSync(serviceName, serviceCtx)
>> }
>>
>> And only pass params and service name, but EntityQuery is not yet available in base component when compiling.
> What do you mean by “EntityQuery is not yet available in base component
> when compiling”?
>
> Can you provide a patch and the command you run to get to this failing
> scenario?
>
>> Anyway it would add much, just a cover function
>>
>> Le 03/10/2019 à 14:29, Jacques Le Roux a écrit :
>>> BTW looking at OrderTests.groovy it seems we can refactor Groovy tests, a lot of is common...
>>>
> --
> Jacques Le Roux
> 400E Chemin de la Mouline
> 34560 Poussan
> 04 67 51 19 38
> 06 11 79 50 28