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.
Anyway it would add much, just a cover function
Jacques
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 03/10/2019 à 13:33, Jacques Le Roux a écrit :
r1867927 is the answer
Jacques
Le 03/10/2019 à 12:10, Mathieu Lirzin a écrit :
Hello Jacques,
Jacques Le Roux <jacques.le.r...@les7arts.com> writes:
Le 02/10/2019 à 17:21, Mathieu Lirzin a écrit :
jler...@apache.org writes:
Author: jleroux
Date: Wed Oct 2 14:46:00 2019
New Revision: 1867889
URL: http://svn.apache.org/viewvc?rev=1867889&view=rev
Log:
Improved: Unit test case for service - SendOrderBackorderNotification
(OFBIZ-8810)(OFBIZ-9647)(OFBIZ-9671)
While working on this I stumbled upon an issue related with
webSiteId="OrderEntry" well related by Ratnesh Upadhyay in OFBIZ-9647.
Unlike him I decided not to remove the webSiteId="OrderEntry" entries but to
replace them by webSiteId="WebStore"
Added:
ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTest.xml
(with props)
It would be nice if you could rewrite this "integration" test in Groovy
or Java.
Yes of course (Groovy preferably IMO)
If I remember correctly we have decided to not accept new minilang code
in our codebase. Am I overlooking something?
Modified:
ofbiz/ofbiz-framework/trunk/applications/datamodel/data/demo/OrderDemoData.xml
ofbiz/ofbiz-framework/trunk/applications/order/servicedef/secas.xml
ofbiz/ofbiz-framework/trunk/applications/order/testdef/OrderTest.xml
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml
Thanks.
We have discussed this already and here is a special case as commented at
bottom of OFBIZ-1463 and at https://markmail.org/message/ute4ulnetz2h4ed5
I don't want to lose the work embedded in this and 15 others patches available
at OFBIZ-1463 (to be checked one by one).
Integration tests are data driven, I mean that when you have defined the data
the test itself mostly follows.
Most of the time it's not a big deal to switch the test from Minilang to Groovy.
I/we can do it after a 1st pass where we value the current patches (already old
for 4 years)
BTW, working on this one I discovered an issue with <<webSiteId="orderEntry">>.
It was not really part of the patch, but the patch revealed it.
Hence (OFBIZ-9647)(OFBIZ-9671) also in this improvement, almost a bug actually
for these 2 Jiras. It was 90% of the time I passed on this commit.
It's incidental but part of the process and I don't want to loose the efforts
put in the remaining available patches.
It's also a matter of not overloading my mind, step by step, if you want.
So I'll continue to check these patches, apply them and later migrate tests to
Groovy.
Then I expect the tests will have been validated and it will be almost
mechanical to migrate them.
But you are right and I'll open new Jiras for migrating them, knowing
that we have a 1300+ others tests to migrate[1]! (ie here it's 1%+,
and I expect simple ones :))
Sorry, but I still don't buy your arguments. :-)
I will repeat what I said in the previous discussion:
* If this is not a big deal to migrate integration tests *why don't you
just™* do the migration work before committing those patches?
* If you don't have time to do it right now, chances are that you won't
have time for it later, so adding more minilang simply means more
burden on others.
I would prefer that we settle this disagreement before you go ahead.
