Re: svn commit: r682246 [1/4] - in /ofbiz/trunk/framework/minilang/src/org/ofbiz/minilang: ./ method/ method/callops/ method/conditional/ method/entityops/ method/envops/ method/eventops/ method/ifops/ method/otherops/ method/serviceops/ operation/

[Bilgin Ibryam]

After these changes I get java.lang.ClassCastException during order creation.
Here is the error message:

2008-08-04 14:24:37,794 (http-0.0.0.0-8443-1) [       SimpleMethod.java:1100:ERROR]
     [java] ---- runtime exception report --------------------------------------------------
     [java] Error in simple-method operation [<iterate list-name="relatedPartyIdList" entry-name="relatedPartyId"/>]: java.lang.ClassCastException: java.lang.String
     [java] Exception: java.lang.ClassCastException
     [java] Message: java.lang.String
     [java] ---- stack trace ---------------------------------------------------------------
     [java] java.lang.ClassCastException: java.lang.String
     [java] org.ofbiz.minilang.method.envops.Iterate.exec(Iterate.java:107)
     [java] org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:1095)
     [java] org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:735)
     [java] org.ofbiz.minilang.method.callops.CallSimpleMethod.exec(CallSimpleMethod.java:75)
     [java] org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:1095)
     [java] org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:735)
     [java] org.ofbiz.minilang.method.callops.CallSimpleMethod.exec(CallSimpleMethod.java:75)
     [java] org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:1095)
     [java] org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:735)
     [java] org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:135)
     [java] org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:117)
     [java] org.ofbiz.minilang.SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:76)
     [java] org.ofbiz.minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:51)
     [java] org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:384)
     [java] org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:213)
     [java] org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149)
     [java] org.ofbiz.accounting.payment.BillingAccountWorker.makePartyBillingAccountList(BillingAccountWorker.java:72)
     [java] sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     [java] sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     [java] sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     [java] java.lang.reflect.Method.invoke(Method.java:585)
     [java] org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
     [java] groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:230)
     [java] groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1105)
     [java] org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:749)
     [java] org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:170)
     [java] CheckoutPayment.run(CheckoutPayment.groovy:54)
     [java] org.ofbiz.base.util.GroovyUtil.runScriptAtLocation(GroovyUtil.java:78)
     [java] org.ofbiz.widget.screen.ModelScreenAction$Script.runAction(ModelScreenAction.java:400)
     [java] org.ofbiz.widget.screen.ModelScreenAction.runSubActions(ModelScreenAction.java:122)
     [java] org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:221)
     [java] org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
     [java] org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:129)
     [java] org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:92)
     [java] org.ofbiz.widget.screen.ScreenWidgetViewHandler.render(ScreenWidgetViewHandler.java:96)
     [java] org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:640)
     [java] org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:425)
     [java] org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:198)
     [java] javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
     [java] javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
     [java] org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
     [java] org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     [java] org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:259)
     [java] org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     [java] org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     [java] org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
     [java] org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
     [java] org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
     [java] org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
     [java] org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
     [java] org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
     [java] org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
     [java] org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
     [java] org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
     [java] org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
     [java] java.lang.Thread.run(Thread.java:595)

[Jacopo Cappellato-3]

yeah,

I am getting (and I have reported a few hours ago) a similar error  
when receiving items into inventory.

Adam, did you get a chance to test the applications using the  
framework components you have modified? If they are working for you,  
then you may have missed to commit a part of your work.

Jacopo

On Aug 4, 2008, at 1:25 PM, Bilgin Ibryam wrote:

> After these changes I get java.lang.ClassCastException during order  
> creation.
> Here is the error message:
>
> 2008-08-04 14:24:37,794 (http-0.0.0.0-8443-1)  
> [       SimpleMethod.java:1100:ERROR]
>     [java] ---- runtime exception report  
> --------------------------------------------------
>     [java] Error in simple-method operation [<iterate list-
> name="relatedPartyIdList" entry-name="relatedPartyId"/>]:  
> java.lang.ClassCastException: java.lang.String
>     [java] Exception: java.lang.ClassCastException
>     [java] Message: java.lang.String
>     [java] ---- stack trace  
> ---------------------------------------------------------------
>     [java] java.lang.ClassCastException: java.lang.String
>     [java]  
> org.ofbiz.minilang.method.envops.Iterate.exec(Iterate.java:107)
>     [java]  
> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:1095)
>     [java] org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:735)
>     [java]  
> org
> .ofbiz
> .minilang.method.callops.CallSimpleMethod.exec(CallSimpleMethod.java:
> 75)
>     [java]  
> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:1095)
>     [java] org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:735)
>     [java]  
> org
> .ofbiz
> .minilang.method.callops.CallSimpleMethod.exec(CallSimpleMethod.java:
> 75)
>     [java]  
> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:1095)
>     [java] org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:735)
>     [java]  
> org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:135)
>     [java]  
> org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:
> 117)
>     [java]  
> org
> .ofbiz
> .minilang
> .SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:76)
>     [java]  
> org
> .ofbiz.minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:
> 51)
>     [java]  
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
> 384)
>     [java]  
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
> 213)
>     [java]  
> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:
> 149)
>     [java]  
> org
> .ofbiz
> .accounting
> .payment
> .BillingAccountWorker
> .makePartyBillingAccountList(BillingAccountWorker.java:72)
>     [java] sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     [java]  
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [java]  
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
>     [java] java.lang.reflect.Method.invoke(Method.java:585)
>     [java]  
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:
> 86)
>     [java] groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:230)
>     [java]  
> groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1105)
>     [java]  
> org
> .codehaus
> .groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:749)
>     [java]  
> org
> .codehaus
> .groovy
> .runtime
> .ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:170)
>     [java] CheckoutPayment.run(CheckoutPayment.groovy:54)
>     [java]  
> org.ofbiz.base.util.GroovyUtil.runScriptAtLocation(GroovyUtil.java:78)
>     [java] org.ofbiz.widget.screen.ModelScreenAction
> $Script.runAction(ModelScreenAction.java:400)
>     [java]  
> org
> .ofbiz
> .widget
> .screen.ModelScreenAction.runSubActions(ModelScreenAction.java:122)
>     [java] org.ofbiz.widget.screen.ModelScreenWidget
> $Section.renderWidgetString(ModelScreenWidget.java:221)
>     [java]  
> org
> .ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:
> 393)
>     [java]  
> org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:129)
>     [java]  
> org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:92)
>     [java]  
> org
> .ofbiz
> .widget
> .screen.ScreenWidgetViewHandler.render(ScreenWidgetViewHandler.java:
> 96)
>     [java]  
> org
> .ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:
> 640)
>     [java]  
> org
> .ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:
> 425)
>     [java]  
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:198)
>     [java] javax.servlet.http.HttpServlet.service(HttpServlet.java:
> 690)
>     [java] javax.servlet.http.HttpServlet.service(HttpServlet.java:
> 803)
>     [java]  
> org
> .apache
> .catalina
> .core
> .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
> 290)
>     [java]  
> org
> .apache
> .catalina
> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>     [java]  
> org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:
> 259)
>     [java]  
> org
> .apache
> .catalina
> .core
> .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
> 235)
>     [java]  
> org
> .apache
> .catalina
> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>     [java]  
> org
> .apache
> .catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
> 233)
>     [java]  
> org
> .apache
> .catalina.core.StandardContextValve.invoke(StandardContextValve.java:
> 175)
>     [java]  
> org
> .apache
> .catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>     [java]  
> org
> .apache
> .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>     [java]  
> org
> .apache
> .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
> 109)
>     [java]  
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
> 568)
>     [java]  
> org
> .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
> 286)
>     [java]  
> org
> .apache.coyote.http11.Http11Processor.process(Http11Processor.java:
> 844)
>     [java] org.apache.coyote.http11.Http11Protocol
> $Http11ConnectionHandler.process(Http11Protocol.java:583)
>     [java] org.apache.tomcat.util.net.JIoEndpoint
> $Worker.run(JIoEndpoint.java:447)
>     [java] java.lang.Thread.run(Thread.java:595)
>

[Adam Heath-2]

Jacopo Cappellato wrote:
> yeah,
>
> I am getting (and I have reported a few hours ago) a similar error when
> receiving items into inventory.
>
> Adam, did you get a chance to test the applications using the framework
> components you have modified? If they are working for you, then you may
> have missed to commit a part of your work.

I did test, but obviously not everything.  It's not possible for a human
to test every single bit of the code; that's why we need more automated
tests.

As for minilang, that is something that can have a rather large and
thorough set of test cases.

This problem is fixed in 682395.

[Jacopo Cappellato-3]

On Aug 4, 2008, at 4:18 PM, Adam Heath wrote:

> Jacopo Cappellato wrote:
>> yeah,
>> I am getting (and I have reported a few hours ago) a similar error  
>> when receiving items into inventory.
>> Adam, did you get a chance to test the applications using the  
>> framework components you have modified? If they are working for  
>> you, then you may have missed to commit a part of your work.
>
> I did test, but obviously not everything.  It's not possible for a  
> human to test every single bit of the code; that's why we need more  
> automated tests.

I agree it would be great to have more and more automated tests;  
however some of the ones that we already have were failing due to the  
casting error in the "iterate" operation... I guess you didn't run  
them :-)

Jacopo

>
>
> As for minilang, that is something that can have a rather large and  
> thorough set of test cases.
>
> This problem is fixed in 682395.

[Adam Heath-2]

Jacopo Cappellato wrote:

>
> On Aug 4, 2008, at 4:18 PM, Adam Heath wrote:
>
>> Jacopo Cappellato wrote:
>>> yeah,
>>> I am getting (and I have reported a few hours ago) a similar error
>>> when receiving items into inventory.
>>> Adam, did you get a chance to test the applications using the
>>> framework components you have modified? If they are working for you,
>>> then you may have missed to commit a part of your work.
>>
>> I did test, but obviously not everything.  It's not possible for a
>> human to test every single bit of the code; that's why we need more
>> automated tests.
>
> I agree it would be great to have more and more automated tests; however
> some of the ones that we already have were failing due to the casting
> error in the "iterate" operation... I guess you didn't run them :-)

You're right, I didn't.  Sorry.

Running tests at the top-level, for the entire container, can be painful
when one is working on an isolated level.  It needs to be simple to run
a tests in smaller chunks.

On that note, I'm going to start working on junit tests for individual
bits of code; minilang will be the first one that I do.  I'll get the
basic stuff started, then it should be easy for others to see how I'm
doing it, and help out with it.

[Jacopo Cappellato-3]

On Aug 4, 2008, at 4:49 PM, Adam Heath wrote:

> Jacopo Cappellato wrote:
>> On Aug 4, 2008, at 4:18 PM, Adam Heath wrote:
>>> Jacopo Cappellato wrote:
>>>> yeah,
>>>> I am getting (and I have reported a few hours ago) a similar  
>>>> error when receiving items into inventory.
>>>> Adam, did you get a chance to test the applications using the  
>>>> framework components you have modified? If they are working for  
>>>> you, then you may have missed to commit a part of your work.
>>>
>>> I did test, but obviously not everything.  It's not possible for a  
>>> human to test every single bit of the code; that's why we need  
>>> more automated tests.
>> I agree it would be great to have more and more automated tests;  
>> however some of the ones that we already have were failing due to  
>> the casting error in the "iterate" operation... I guess you didn't  
>> run them :-)
>
> You're right, I didn't.  Sorry.

No need to apologize, you are doing a big amount of code changes and  
issues like this can rather easily be introduced.
>
> Running tests at the top-level, for the entire container, can be  
> painful when one is working on an isolated level.  It needs to be  
> simple to run a tests in smaller chunks.
>

I know there is a way to run the tests on a single component, I don't  
remember the syntax, but it should be rather easy to find somewhere  
(Confluence or ML).

> On that note, I'm going to start working on junit tests for  
> individual bits of code; minilang will be the first one that I do.  
> I'll get the basic stuff started, then it should be easy for others  
> to see how I'm doing it, and help out with it.

More automatic tests on framework component are welcome (as the ones  
on application level components)!

Jacopo

[Tim Ruppert]

+1

On Aug 4, 2008, at 8:49 AM, Adam Heath wrote:

> Jacopo Cappellato wrote:
>> On Aug 4, 2008, at 4:18 PM, Adam Heath wrote:
>>> Jacopo Cappellato wrote:
>>>> yeah,
>>>> I am getting (and I have reported a few hours ago) a similar  
>>>> error when receiving items into inventory.
>>>> Adam, did you get a chance to test the applications using the  
>>>> framework components you have modified? If they are working for  
>>>> you, then you may have missed to commit a part of your work.
>>>
>>> I did test, but obviously not everything.  It's not possible for a  
>>> human to test every single bit of the code; that's why we need  
>>> more automated tests.
>> I agree it would be great to have more and more automated tests;  
>> however some of the ones that we already have were failing due to  
>> the casting error in the "iterate" operation... I guess you didn't  
>> run them :-)
>
> You're right, I didn't.  Sorry.
>
> Running tests at the top-level, for the entire container, can be  
> painful when one is working on an isolated level.  It needs to be  
> simple to run a tests in smaller chunks.
>
> On that note, I'm going to start working on junit tests for  
> individual bits of code; minilang will be the first one that I do.  
> I'll get the basic stuff started, then it should be easy for others  
> to see how I'm doing it, and help out with it.

[David E Jones]

On Mon, 4 Aug 2008 17:02:56 +0200, Jacopo Cappellato <[hidden email]> wrote:

>
> On Aug 4, 2008, at 4:49 PM, Adam Heath wrote:
>> Running tests at the top-level, for the entire container, can be
>> painful when one is working on an isolated level.  It needs to be
>> simple to run a tests in smaller chunks.
>>
>
> I know there is a way to run the tests on a single component, I don't
> remember the syntax, but it should be rather easy to find somewhere
> (Confluence or ML).

There is documentation in the Technical Production Setup Guide (http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide) in the "Running OFBiz Automated Tests" section. I'm not sure if that's the best place for it, and in fact we should probably move it to the Demo and Test Setup Guide (http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide).

Anyway, it has info about running tests per component, and I think there are even some ways to run more granular tests but I don't remember them off the top of my head.

Fortunately for us we all "read Java" and can look at the test run container implementation to see the options, and add more if we're not satisfied.

Being upset about inadequate automated tests (though actually we have hundreds of them) is a good thing, as long as that translates into action... ;)

-David

[Adam Heath-2]

David Jones wrote:
>
> Being upset about inadequate automated tests (though actually we
 > have hundreds of them) is a good thing, as long as that translates
 > into action... ;)

Oh, it'll translate into action, most definately.

I do have a question, tho.  For java-level test cases, would it be
better to have the test code side-by-side with the main classes, or in a
different top-level src tree?  Ie, like this:

src/org/ofbiz/minilang/method/callops/CreateObject.java
src/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java

or:

src/java/org/ofbiz/minilang/method/callops/CreateObject.java
src/tests/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java

I prefer the former, as it keeps the main code closer to it's test code,
so it's easier to discover problems.

[Adrian Crum]

Or have a common, pre-defined test method signature kept in the class
itself.

-Adrian

Adam Heath wrote:

> David Jones wrote:
>>
>> Being upset about inadequate automated tests (though actually we
>  > have hundreds of them) is a good thing, as long as that translates
>  > into action... ;)
>
> Oh, it'll translate into action, most definately.
>
> I do have a question, tho.  For java-level test cases, would it be
> better to have the test code side-by-side with the main classes, or in a
> different top-level src tree?  Ie, like this:
>
> src/org/ofbiz/minilang/method/callops/CreateObject.java
> src/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java
>
> or:
>
> src/java/org/ofbiz/minilang/method/callops/CreateObject.java
> src/tests/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java
>
> I prefer the former, as it keeps the main code closer to it's test code,
> so it's easier to discover problems.
>

[Tim Ruppert]

I like either one - I normally had them separated like the latter, but  
the former is coolio as well.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Aug 4, 2008, at 11:19 AM, Adam Heath wrote:

> David Jones wrote:
>> Being upset about inadequate automated tests (though actually we
> > have hundreds of them) is a good thing, as long as that translates
> > into action... ;)
>
> Oh, it'll translate into action, most definately.
>
> I do have a question, tho.  For java-level test cases, would it be  
> better to have the test code side-by-side with the main classes, or  
> in a different top-level src tree?  Ie, like this:
>
> src/org/ofbiz/minilang/method/callops/CreateObject.java
> src/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java
>
> or:
>
> src/java/org/ofbiz/minilang/method/callops/CreateObject.java
> src/tests/org/ofbiz/minilang/method/callops/tests/
> CreateObjectTest.java
>
> I prefer the former, as it keeps the main code closer to it's test  
> code, so it's easier to discover problems.

[Adam Heath-2]

Adrian Crum wrote:
> Or have a common, pre-defined test method signature kept in the class
> itself.

Er, no, absolutely not.  Then, that method will be taking up memory at
runtime.

[Adam Heath-2]

Adam Heath wrote:

> src/org/ofbiz/minilang/method/callops/CreateObject.java
> src/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java
>
> or:
>
> src/java/org/ofbiz/minilang/method/callops/CreateObject.java
> src/tests/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java

Of course, renaming everything to fit like the second example is a *lot*
of churn, which doesn't sit well with me.  For now, I'll probably do it
as the former, until we still getting tons, then we can revisit it.

[Jacques Le Roux]

I prefer the 1st but this idea of test method signature is interesting too

Jacques

From: "Adrian Crum" <[hidden email]>

> Or have a common, pre-defined test method signature kept in the class
> itself.
>
> -Adrian
>
> Adam Heath wrote:
>> David Jones wrote:
>>>
>>> Being upset about inadequate automated tests (though actually we
>>  > have hundreds of them) is a good thing, as long as that translates
>>  > into action... ;)
>>
>> Oh, it'll translate into action, most definately.
>>
>> I do have a question, tho.  For java-level test cases, would it be
>> better to have the test code side-by-side with the main classes, or in a
>> different top-level src tree?  Ie, like this:
>>
>> src/org/ofbiz/minilang/method/callops/CreateObject.java
>> src/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java
>>
>> or:
>>
>> src/java/org/ofbiz/minilang/method/callops/CreateObject.java
>> src/tests/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java
>>
>> I prefer the former, as it keeps the main code closer to it's test code,
>> so it's easier to discover problems.
>>
>

[Adam Heath-2]

Jacopo Cappellato wrote:

> No need to apologize, you are doing a big amount of code changes and
> issues like this can rather easily be introduced.

But I'm perfect, a god.  I'm right, you're all wrong.  Now pay me a
million dollars.

:)

[David E Jones]

On Mon, 04 Aug 2008 13:14:47 -0500, Adam Heath <[hidden email]> wrote:
> Jacopo Cappellato wrote:
>
>> No need to apologize, you are doing a big amount of code changes and
>> issues like this can rather easily be introduced.
>
> But I'm perfect, a god.  I'm right, you're all wrong.  Now pay me a
> million dollars.

Ah hah! You blew your cover!

We now know you're not a god, because what use does a god have for a million dollars? ;)

-David

[David E Jones]

On Mon, 04 Aug 2008 12:41:52 -0500, Adam Heath <[hidden email]> wrote:

> Adam Heath wrote:
>
>> src/org/ofbiz/minilang/method/callops/CreateObject.java
>> src/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java
>>
>> or:
>>
>> src/java/org/ofbiz/minilang/method/callops/CreateObject.java
>> src/tests/org/ofbiz/minilang/method/callops/tests/CreateObjectTest.java
>
> Of course, renaming everything to fit like the second example is a *lot*
> of churn, which doesn't sit well with me.  For now, I'll probably do it
> as the former, until we still getting tons, then we can revisit it.

Yeah, whatever we do I wouldn't want to move around a bunch of existing source as it causes people lots of problems.

The general direction taken so far is to make sure that tests go in the same component (as much as applicable) as the functionality being tested, but beyond that I guess it depends on how the test is being written and such. If it is in Java then along with the other stuff would be nice, like your first option.

-David

[BJ Freeman]

sounds more like a delusional problem
:D

Adam Heath sent the following on 8/4/2008 11:14 AM:

> Jacopo Cappellato wrote:
>
>> No need to apologize, you are doing a big amount of code changes and
>> issues like this can rather easily be introduced.
>
> But I'm perfect, a god.  I'm right, you're all wrong.  Now pay me a
> million dollars.
>
> :)
>
>
>