Proposal: Mandatory JUnit tests for new functions

[hans_bakker]

Good morning,

If you are following the relatively new developments in software
development you will be aware of continuous integration or the next
step: continuous deployment. This is all part of the 'continuous
improvement' principle.
When the OFBiz system was initially implemented this was already
recognized that automated tests are required for a quality product.

Therefore my proposal that:
1. New functions must have automated tests in the same commit in order
to be considered for the trunk.
2. Existing functions which are extended will need a JUnit test the same
as new functions.
3. The introduction of a test framework for on-line screens which can
run in batched mode.
4. Reporting of an error should be done by providing an automated test
which shows the error.

You might want to read an article I wrote on this subject with at the
end links to the originators of this principle:
https://www.linkedin.com/pulse/article/20140909060033-1227556-upgrade-your-erp-system-like-a-phone-app

So please let me know what you think?

Regards,Hans

[Scott Gray-2]

Hi Hans,

Two thoughts:
1. Are we sure we want to raise the barrier for any new potential major contributions?  We don't receive so many as it is.  Same thing with bug reports, would we ignore them if they don't have a test?  Would we delay fixing the issue until someone feels like writing one?
2. IMO unit tests usually only provide value to prevent against regression.  Obviously the tests would pass when committed and as such can't be used as a measure of the quality of a given contribution.

On the other hand, preventing regression is also a very important goal and existing unit tests are extremely useful when making changes in the code base.  Writing unit tests is definitely something to be encouraged any way we can.

Lastly, the majority of our tests are implemented in mini-lang and I'm really not a fan of it at all.  If there were support for converting them to groovy (do we even support groovy tests?), I'd be glad to help lead that change.

Regards
Scott

On 6/10/2014, at 2:49 pm, Hans Bakker <[hidden email]> wrote:

> Good morning,
>
> If you are following the relatively new developments in software development you will be aware of continuous integration or the next step: continuous deployment. This is all part of the 'continuous improvement' principle.
> When the OFBiz system was initially implemented this was already recognized that automated tests are required for a quality product.
>
> Therefore my proposal that:
> 1. New functions must have automated tests in the same commit in order to be considered for the trunk.
> 2. Existing functions which are extended will need a JUnit test the same as new functions.
> 3. The introduction of a test framework for on-line screens which can run in batched mode.
> 4. Reporting of an error should be done by providing an automated test which shows the error.
>
> You might want to read an article I wrote on this subject with at the end links to the originators of this principle:
> https://www.linkedin.com/pulse/article/20140909060033-1227556-upgrade-your-erp-system-like-a-phone-app
>
> So please let me know what you think?
>
> Regards,Hans
>

[hans_bakker]

On 06/10/14 09:15, Scott Gray wrote:
> Hi Hans,
> ..........
> Lastly, the majority of our tests are implemented in mini-lang and I'm really not a fan of it at all.  If there were support for converting them to groovy (do we even support groovy tests?), I'd be glad to help lead that change.
>
Try if groovy is supported in tests and when not add it? You are one of
the few who can make this happen.....

and then, start with OFBIZ-5699?

Regards,'Hans

[Scott Gray-2]

On 6/10/2014, at 3:24 pm, Hans Bakker <[hidden email]> wrote:

> On 06/10/14 09:15, Scott Gray wrote:
>> Hi Hans,
>> ..........
>> Lastly, the majority of our tests are implemented in mini-lang and I'm really not a fan of it at all.  If there were support for converting them to groovy (do we even support groovy tests?), I'd be glad to help lead that change.
>>
> Try if groovy is supported in tests and when not add it? You are one of the few who can make this happen.....
>
> and then, start with OFBIZ-5699?
>
> Regards,'Hans

That won't happen any time soon, I'll be dealing with the conversion to EntityQuery for the foreseeable future.

I was just expressing a few thoughts.  One other: perhaps start small by agreeing that no ticket should be closed until unit tests are added?

Regards
Scott

[Adrian Crum-3]

Unit tests should be encouraged, but not required.

I don't know what you mean by "When the OFBiz system was initially
implemented this was already recognized that automated tests are
required for a quality product." If you are referring to the OFBiz
"product" then it is important to remember that unit tests were
practically non-existent prior to 2007.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/6/2014 2:49 AM, Hans Bakker wrote:

> Good morning,
>
> If you are following the relatively new developments in software
> development you will be aware of continuous integration or the next
> step: continuous deployment. This is all part of the 'continuous
> improvement' principle.
> When the OFBiz system was initially implemented this was already
> recognized that automated tests are required for a quality product.
>
> Therefore my proposal that:
> 1. New functions must have automated tests in the same commit in order
> to be considered for the trunk.
> 2. Existing functions which are extended will need a JUnit test the same
> as new functions.
> 3. The introduction of a test framework for on-line screens which can
> run in batched mode.
> 4. Reporting of an error should be done by providing an automated test
> which shows the error.
>
> You might want to read an article I wrote on this subject with at the
> end links to the originators of this principle:
> https://www.linkedin.com/pulse/article/20140909060033-1227556-upgrade-your-erp-system-like-a-phone-app
>
>
> So please let me know what you think?
>
> Regards,Hans
>

[Jacopo Cappellato-4]

a big +1 to put more "social" pressure on contributors to provide and implement unit tests; it will be a big win when we all new code will be committed with unit tests, so I agree that it is the way to go but I just want to be realistic and enforcing this rule may have a big impact on the project (not all negative indeed).
at the moment I would cast a -1 for making this rule mandatory; maybe we could enforce it as a condition to backport a fix to a release branch but I am not sure

But we should also review the toolset we have in OFBiz for unit tests, for example:
1) I dislike Minilang unit tests; we should ask for Groovy or Java tests
2) I don't like the fact that you have to add configuration to ofbiz-component.xml and testdef folder; we should instead stick to a more traditional usage of JUnit

Jacopo


On Oct 6, 2014, at 3:49 AM, Hans Bakker <[hidden email]> wrote:

> Good morning,
>
> If you are following the relatively new developments in software development you will be aware of continuous integration or the next step: continuous deployment. This is all part of the 'continuous improvement' principle.
> When the OFBiz system was initially implemented this was already recognized that automated tests are required for a quality product.
>
> Therefore my proposal that:
> 1. New functions must have automated tests in the same commit in order to be considered for the trunk.
> 2. Existing functions which are extended will need a JUnit test the same as new functions.
> 3. The introduction of a test framework for on-line screens which can run in batched mode.
> 4. Reporting of an error should be done by providing an automated test which shows the error.
>
> You might want to read an article I wrote on this subject with at the end links to the originators of this principle:
> https://www.linkedin.com/pulse/article/20140909060033-1227556-upgrade-your-erp-system-like-a-phone-app
>
> So please let me know what you think?
>
> Regards,Hans
>

[hans_bakker]

So Scott,

you introduce a new API named EntityQuery without a unit test, then you
are going to replace the existing well working API with something which
is not tested continuously....

i love the idea :-(

and then everybody asking for reliability and quality.....

Regards,
Hans

On 06/10/14 09:43, Scott Gray wrote:

> On 6/10/2014, at 3:24 pm, Hans Bakker <[hidden email]> wrote:
>
>> On 06/10/14 09:15, Scott Gray wrote:
>>> Hi Hans,
>>> ..........
>>> Lastly, the majority of our tests are implemented in mini-lang and I'm really not a fan of it at all.  If there were support for converting them to groovy (do we even support groovy tests?), I'd be glad to help lead that change.
>>>
>>> and then, start with OFBIZ-5699?
>>>
>>> Regards,'Hans
> That won't happen any time soon, I'll be dealing with the conversion to EntityQuery for the foreseeable future.
>
> Regards
> Scott

[Scott Gray-2]

Like I said in my earlier email, new unit tests only prevent future regression they don't serve as an indicator to the quality of the contribution they're submitted with.  If I were to provide unit tests for the EntityQuery class it would tell you exactly zero about whether or not upgrading existing code to the new API will have any problems.  Only pre-existing unit tests can give an indication of regression for new code changes.

We already have unit tests for lots of the code that will be upgraded to the new API and I'm fairly confident those tests will catch any issues with the EntityQuery class (because it would be a regression to existing code).

But to allay your fears about the lack of unit tests, I believe an HWM developer is planning to contribute some tests for the EntityQuery class.  Please also keep in mind that the new API actually uses the existing Delegator API so there is not really much new logic or functionality here, just an enhanced way to access the same old thing.

Regards
Scott

On 6/10/2014, at 7:14 pm, Hans Bakker <[hidden email]> wrote:

> So Scott,
>
> you introduce a new API named EntityQuery without a unit test, then you are going to replace the existing well working API with something which is not tested continuously....
>
> i love the idea :-(
>
> and then everybody asking for reliability and quality.....
>
> Regards,
> Hans
>
> On 06/10/14 09:43, Scott Gray wrote:
>> On 6/10/2014, at 3:24 pm, Hans Bakker <[hidden email]> wrote:
>>
>>> On 06/10/14 09:15, Scott Gray wrote:
>>>> Hi Hans,
>>>> ..........
>>>> Lastly, the majority of our tests are implemented in mini-lang and I'm really not a fan of it at all.  If there were support for converting them to groovy (do we even support groovy tests?), I'd be glad to help lead that change.
>>>>
>>>> and then, start with OFBIZ-5699?
>>>>
>>>> Regards,'Hans
>> That won't happen any time soon, I'll be dealing with the conversion to EntityQuery for the foreseeable future.
>>
>> Regards
>> Scott
>

[Jacopo Cappellato-4]

A few days ago Scott and I had already discussed about unit tests for the new query builder and they will come soon: the new API will not go into any release without unit tests.
In fact I think that Scott told you that he is not going to work on OFBIZ-5699 because he is busy with the query builder API at the moment: but that ticket is completely unrelated to it and I am not sure why you are asking him to work on it.

Jacopo

On Oct 6, 2014, at 8:14 AM, Hans Bakker <[hidden email]> wrote:

> So Scott,
>
> you introduce a new API named EntityQuery without a unit test, then you are going to replace the existing well working API with something which is not tested continuously....
>
> i love the idea :-(
>
> and then everybody asking for reliability and quality.....
>
> Regards,
> Hans
>
> On 06/10/14 09:43, Scott Gray wrote:
>> On 6/10/2014, at 3:24 pm, Hans Bakker <[hidden email]> wrote:
>>
>>> On 06/10/14 09:15, Scott Gray wrote:
>>>> Hi Hans,
>>>> ..........
>>>> Lastly, the majority of our tests are implemented in mini-lang and I'm really not a fan of it at all.  If there were support for converting them to groovy (do we even support groovy tests?), I'd be glad to help lead that change.
>>>>
>>>> and then, start with OFBIZ-5699?
>>>>
>>>> Regards,'Hans
>> That won't happen any time soon, I'll be dealing with the conversion to EntityQuery for the foreseeable future.
>>
>> Regards
>> Scott
>

[hans_bakker]

Jacopo, I stand corrected! yes indeed the wrong Issue.

not 2699 but OFBIZ-4053, you are right.

Thank you and Scott for supporting  the idea, so we get the quality of
OFBiz better.....

Left one open question to answer, how we are going to include user
interface tests.

Once we had selenium included, however it was removed....are there
alternatives?

Regards,'Hans


On 06/10/14 13:31, Jacopo Cappellato wrote:

> A few days ago Scott and I had already discussed about unit tests for the new query builder and they will come soon: the new API will not go into any release without unit tests.
> In fact I think that Scott told you that he is not going to work on OFBIZ-5699 because he is busy with the query builder API at the moment: but that ticket is completely unrelated to it and I am not sure why you are asking him to work on it.
>
> Jacopo
>
> On Oct 6, 2014, at 8:14 AM, Hans Bakker <[hidden email]> wrote:
>
>> So Scott,
>>
>> you introduce a new API named EntityQuery without a unit test, then you are going to replace the existing well working API with something which is not tested continuously....
>>
>> i love the idea :-(
>>
>> and then everybody asking for reliability and quality.....
>>
>> Regards,
>> Hans
>>
>> On 06/10/14 09:43, Scott Gray wrote:
>>> On 6/10/2014, at 3:24 pm, Hans Bakker <[hidden email]> wrote:
>>>
>>>> On 06/10/14 09:15, Scott Gray wrote:
>>>>> Hi Hans,
>>>>> ..........
>>>>> Lastly, the majority of our tests are implemented in mini-lang and I'm really not a fan of it at all.  If there were support for converting them to groovy (do we even support groovy tests?), I'd be glad to help lead that change.
>>>>>
>>>>> and then, start with OFBIZ-5699?
>>>>>
>>>>> Regards,'Hans
>>> That won't happen any time soon, I'll be dealing with the conversion to EntityQuery for the foreseeable future.
>>>
>>> Regards
>>> Scott

[Jacopo Cappellato-4]

Let's keep thinking and talking about how to improve our toolset for unit tests (and ui tests).I would also add to the mix load and performance tests.
It is important that we do not only select the tools we consider important but also how we use them in OFBiz.
I have also some ideas floating in my brain about how to unit test services but not ready to share it at the moment.
But it is great to discuss about these things.

Jacopo

On Oct 6, 2014, at 8:44 AM, Hans Bakker <[hidden email]> wrote:

> Jacopo, I stand corrected! yes indeed the wrong Issue.
>
> not 2699 but OFBIZ-4053, you are right.
>
> Thank you and Scott for supporting  the idea, so we get the quality of OFBiz better.....
>
> Left one open question to answer, how we are going to include user interface tests.
>
> Once we had selenium included, however it was removed....are there alternatives?
>
> Regards,'Hans
>
>
> On 06/10/14 13:31, Jacopo Cappellato wrote:
>> A few days ago Scott and I had already discussed about unit tests for the new query builder and they will come soon: the new API will not go into any release without unit tests.
>> In fact I think that Scott told you that he is not going to work on OFBIZ-5699 because he is busy with the query builder API at the moment: but that ticket is completely unrelated to it and I am not sure why you are asking him to work on it.
>>
>> Jacopo
>>
>> On Oct 6, 2014, at 8:14 AM, Hans Bakker <[hidden email]> wrote:
>>
>>> So Scott,
>>>
>>> you introduce a new API named EntityQuery without a unit test, then you are going to replace the existing well working API with something which is not tested continuously....
>>>
>>> i love the idea :-(
>>>
>>> and then everybody asking for reliability and quality.....
>>>
>>> Regards,
>>> Hans
>>>
>>> On 06/10/14 09:43, Scott Gray wrote:
>>>> On 6/10/2014, at 3:24 pm, Hans Bakker <[hidden email]> wrote:
>>>>
>>>>> On 06/10/14 09:15, Scott Gray wrote:
>>>>>> Hi Hans,
>>>>>> ..........
>>>>>> Lastly, the majority of our tests are implemented in mini-lang and I'm really not a fan of it at all.  If there were support for converting them to groovy (do we even support groovy tests?), I'd be glad to help lead that change.
>>>>>>
>>>>>> and then, start with OFBIZ-5699?
>>>>>>
>>>>>> Regards,'Hans
>>>> That won't happen any time soon, I'll be dealing with the conversion to EntityQuery for the foreseeable future.
>>>>
>>>> Regards
>>>> Scott
>

[taher]

I personally think all the testing we need is in JUnit, Selenium and JMeter
for unit, integration and performance testing respectively. Unfortunately
we are firing selenium after and above OFBiz using gradle scripts.
Integration of Selenium into the framework is necessary in my opinion and
not only that but also into the core framework, not as a specialpurpose
component.

Unit tests are extremely useful and I do not mind at all to add them myself
while contributing anythying. However it is also difficult and requires
focused and deep thinking. So contributors should be mentored by senior
developers which is something not happening in here.

Raising the bar requires heavy mentoring, in all honesty i had to elbow my
way in and learned ofbiz the hard way. If a bug was submitted i usually had
to figure it out myself how to fix it. So in such atmosphere i'm not sure
if enforcing tests is the best option

Taher Alkhateeb.
On Oct 6, 2014 1:03 PM, "Jacopo Cappellato" <
[hidden email]> wrote:

> Let's keep thinking and talking about how to improve our toolset for unit
> tests (and ui tests).I would also add to the mix load and performance tests.
> It is important that we do not only select the tools we consider important
> but also how we use them in OFBiz.
> I have also some ideas floating in my brain about how to unit test
> services but not ready to share it at the moment.
> But it is great to discuss about these things.
>
> Jacopo
>
> On Oct 6, 2014, at 8:44 AM, Hans Bakker <[hidden email]>
> wrote:
>
> > Jacopo, I stand corrected! yes indeed the wrong Issue.
> >
> > not 2699 but OFBIZ-4053, you are right.
> >
> > Thank you and Scott for supporting  the idea, so we get the quality of
> OFBiz better.....
> >
> > Left one open question to answer, how we are going to include user
> interface tests.
> >
> > Once we had selenium included, however it was removed....are there
> alternatives?
> >
> > Regards,'Hans
> >
> >
> > On 06/10/14 13:31, Jacopo Cappellato wrote:
> >> A few days ago Scott and I had already discussed about unit tests for
> the new query builder and they will come soon: the new API will not go into
> any release without unit tests.
> >> In fact I think that Scott told you that he is not going to work on
> OFBIZ-5699 because he is busy with the query builder API at the moment: but
> that ticket is completely unrelated to it and I am not sure why you are
> asking him to work on it.
> >>
> >> Jacopo
> >>
> >> On Oct 6, 2014, at 8:14 AM, Hans Bakker <[hidden email]>
> wrote:
> >>
> >>> So Scott,
> >>>
> >>> you introduce a new API named EntityQuery without a unit test, then
> you are going to replace the existing well working API with something which
> is not tested continuously....
> >>>
> >>> i love the idea :-(
> >>>
> >>> and then everybody asking for reliability and quality.....
> >>>
> >>> Regards,
> >>> Hans
> >>>
> >>> On 06/10/14 09:43, Scott Gray wrote:
> >>>> On 6/10/2014, at 3:24 pm, Hans Bakker <[hidden email]>
> wrote:
> >>>>
> >>>>> On 06/10/14 09:15, Scott Gray wrote:
> >>>>>> Hi Hans,
> >>>>>> ..........
> >>>>>> Lastly, the majority of our tests are implemented in mini-lang and
> I'm really not a fan of it at all.  If there were support for converting
> them to groovy (do we even support groovy tests?), I'd be glad to help lead
> that change.
> >>>>>>
> >>>>>> and then, start with OFBIZ-5699?
> >>>>>>
> >>>>>> Regards,'Hans
> >>>> That won't happen any time soon, I'll be dealing with the conversion
> to EntityQuery for the foreseeable future.
> >>>>
> >>>> Regards
> >>>> Scott
> >
>
>

[Jacques Le Roux]

Here is my vote inline

Le 06/10/2014 03:49, Hans Bakker a écrit :
> Good morning,
>
> If you are following the relatively new developments in software development you will be aware of continuous integration or the next step:
> continuous deployment. This is all part of the 'continuous improvement' principle.
> When the OFBiz system was initially implemented this was already recognized that automated tests are required for a quality product.
>
> Therefore my proposal that:
> 1. New functions must have automated tests in the same commit in order to be considered for the trunk.
-1 (I agree with opinions already expressed: not mandatory but highly recommended)
> 2. Existing functions which are extended will need a JUnit test the same as new functions.
-1 (idem)
> 3. The introduction of a test framework for on-line screens which can run in batched mode.
+1 (you might be interested by https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20text%20~%20%22selenium%22)
> 4. Reporting of an error should be done by providing an automated test which shows the error.
0 (again, not mandatory but recommended, we must stay realist)

Jacques
>
> You might want to read an article I wrote on this subject with at the end links to the originators of this principle:
> https://www.linkedin.com/pulse/article/20140909060033-1227556-upgrade-your-erp-system-like-a-phone-app
>
> So please let me know what you think?
>
> Regards,Hans
>
>

[Nicolas Malin-2]

For the issue OFBIZ-5699, it was already in my mind to complete unit test ;)

In most case, add/improve/complete the unit test will be very beneficial
for the quality project. But set it as mandatory, I fear that will be a
contribution brake.
+1 for encourage it ! I'm sure some contributor want contribute but they
don't know what doing, and create unit test it's easier, formative and
helpful : so go on :) .

Nicolas

Le 06/10/2014 08:44, Hans Bakker a écrit :

> Jacopo, I stand corrected! yes indeed the wrong Issue.
>
> not 2699 but OFBIZ-4053, you are right.
>
> Thank you and Scott for supporting  the idea, so we get the quality of
> OFBiz better.....
>
> Left one open question to answer, how we are going to include user
> interface tests.
>
> Once we had selenium included, however it was removed....are there
> alternatives?
>
> Regards,'Hans
>
>
> On 06/10/14 13:31, Jacopo Cappellato wrote:
>> A few days ago Scott and I had already discussed about unit tests for
>> the new query builder and they will come soon: the new API will not
>> go into any release without unit tests.
>> In fact I think that Scott told you that he is not going to work on
>> OFBIZ-5699 because he is busy with the query builder API at the
>> moment: but that ticket is completely unrelated to it and I am not
>> sure why you are asking him to work on it.
>>
>> Jacopo
>>
>> On Oct 6, 2014, at 8:14 AM, Hans Bakker
>> <[hidden email]> wrote:
>>
>>> So Scott,
>>>
>>> you introduce a new API named EntityQuery without a unit test, then
>>> you are going to replace the existing well working API with
>>> something which is not tested continuously....
>>>
>>> i love the idea :-(
>>>
>>> and then everybody asking for reliability and quality.....
>>>
>>> Regards,
>>> Hans
>>>
>>> On 06/10/14 09:43, Scott Gray wrote:
>>>> On 6/10/2014, at 3:24 pm, Hans Bakker
>>>> <[hidden email]> wrote:
>>>>
>>>>> On 06/10/14 09:15, Scott Gray wrote:
>>>>>> Hi Hans,
>>>>>> ..........
>>>>>> Lastly, the majority of our tests are implemented in mini-lang
>>>>>> and I'm really not a fan of it at all.  If there were support for
>>>>>> converting them to groovy (do we even support groovy tests?), I'd
>>>>>> be glad to help lead that change.
>>>>>>
>>>>>> and then, start with OFBIZ-5699?
>>>>>>
>>>>>> Regards,'Hans
>>>> That won't happen any time soon, I'll be dealing with the
>>>> conversion to EntityQuery for the foreseeable future.
>>>>
>>>> Regards
>>>> Scott
>

[hans_bakker]

Hi Nicolas,

thanks also you for the support for this proposal.... it started
actually with the commit of Scott, which initially did not have a test,
that seems to be already resolved.
I get really concerned when new especially framework functionality is
added to the trunk without proper automated tests. These days that is
hardly acceptable anymore...

Regards,'
Hans

On 07/10/14 14:50, Nicolas Malin wrote:

> For the issue OFBIZ-5699, it was already in my mind to complete unit
> test ;)
>
> In most case, add/improve/complete the unit test will be very
> beneficial for the quality project. But set it as mandatory, I fear
> that will be a contribution brake.
> +1 for encourage it ! I'm sure some contributor want contribute but
> they don't know what doing, and create unit test it's easier,
> formative and helpful : so go on :) .
>
> Nicolas
>
> Le 06/10/2014 08:44, Hans Bakker a écrit :
>> Jacopo, I stand corrected! yes indeed the wrong Issue.
>>
>> not 2699 but OFBIZ-4053, you are right.
>>
>> Thank you and Scott for supporting  the idea, so we get the quality
>> of OFBiz better.....
>>
>> Left one open question to answer, how we are going to include user
>> interface tests.
>>
>> Once we had selenium included, however it was removed....are there
>> alternatives?
>>
>> Regards,'Hans
>>
>>
>> On 06/10/14 13:31, Jacopo Cappellato wrote:
>>> A few days ago Scott and I had already discussed about unit tests
>>> for the new query builder and they will come soon: the new API will
>>> not go into any release without unit tests.
>>> In fact I think that Scott told you that he is not going to work on
>>> OFBIZ-5699 because he is busy with the query builder API at the
>>> moment: but that ticket is completely unrelated to it and I am not
>>> sure why you are asking him to work on it.
>>>
>>> Jacopo
>>>
>>> On Oct 6, 2014, at 8:14 AM, Hans Bakker
>>> <[hidden email]> wrote:
>>>
>>>> So Scott,
>>>>
>>>> you introduce a new API named EntityQuery without a unit test, then
>>>> you are going to replace the existing well working API with
>>>> something which is not tested continuously....
>>>>
>>>> i love the idea :-(
>>>>
>>>> and then everybody asking for reliability and quality.....
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>> On 06/10/14 09:43, Scott Gray wrote:
>>>>> On 6/10/2014, at 3:24 pm, Hans Bakker
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>> On 06/10/14 09:15, Scott Gray wrote:
>>>>>>> Hi Hans,
>>>>>>> ..........
>>>>>>> Lastly, the majority of our tests are implemented in mini-lang
>>>>>>> and I'm really not a fan of it at all.  If there were support
>>>>>>> for converting them to groovy (do we even support groovy
>>>>>>> tests?), I'd be glad to help lead that change.
>>>>>>>
>>>>>>> and then, start with OFBIZ-5699?
>>>>>>>
>>>>>>> Regards,'Hans
>>>>> That won't happen any time soon, I'll be dealing with the
>>>>> conversion to EntityQuery for the foreseeable future.
>>>>>
>>>>> Regards
>>>>> Scott
>>
>

[Jacques Le Roux]

I agree Hans, it's good to know that Jacopo and Scott's had the same concern and have already taken action :)

Jacques

Le 07/10/2014 10:06, Hans Bakker a écrit :

> Hi Nicolas,
>
> thanks also you for the support for this proposal.... it started actually with the commit of Scott, which initially did not have a test, that seems
> to be already resolved.
> I get really concerned when new especially framework functionality is added to the trunk without proper automated tests. These days that is hardly
> acceptable anymore...
>
> Regards,'
> Hans
>
> On 07/10/14 14:50, Nicolas Malin wrote:
>> For the issue OFBIZ-5699, it was already in my mind to complete unit test ;)
>>
>> In most case, add/improve/complete the unit test will be very beneficial for the quality project. But set it as mandatory, I fear that will be a
>> contribution brake.
>> +1 for encourage it ! I'm sure some contributor want contribute but they don't know what doing, and create unit test it's easier, formative and
>> helpful : so go on :) .
>>
>> Nicolas
>>
>> Le 06/10/2014 08:44, Hans Bakker a écrit :
>>> Jacopo, I stand corrected! yes indeed the wrong Issue.
>>>
>>> not 2699 but OFBIZ-4053, you are right.
>>>
>>> Thank you and Scott for supporting  the idea, so we get the quality of OFBiz better.....
>>>
>>> Left one open question to answer, how we are going to include user interface tests.
>>>
>>> Once we had selenium included, however it was removed....are there alternatives?
>>>
>>> Regards,'Hans
>>>
>>>
>>> On 06/10/14 13:31, Jacopo Cappellato wrote:
>>>> A few days ago Scott and I had already discussed about unit tests for the new query builder and they will come soon: the new API will not go into
>>>> any release without unit tests.
>>>> In fact I think that Scott told you that he is not going to work on OFBIZ-5699 because he is busy with the query builder API at the moment: but
>>>> that ticket is completely unrelated to it and I am not sure why you are asking him to work on it.
>>>>
>>>> Jacopo
>>>>
>>>> On Oct 6, 2014, at 8:14 AM, Hans Bakker <[hidden email]> wrote:
>>>>
>>>>> So Scott,
>>>>>
>>>>> you introduce a new API named EntityQuery without a unit test, then you are going to replace the existing well working API with something which
>>>>> is not tested continuously....
>>>>>
>>>>> i love the idea :-(
>>>>>
>>>>> and then everybody asking for reliability and quality.....
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>> On 06/10/14 09:43, Scott Gray wrote:
>>>>>> On 6/10/2014, at 3:24 pm, Hans Bakker <[hidden email]> wrote:
>>>>>>
>>>>>>> On 06/10/14 09:15, Scott Gray wrote:
>>>>>>>> Hi Hans,
>>>>>>>> ..........
>>>>>>>> Lastly, the majority of our tests are implemented in mini-lang and I'm really not a fan of it at all.  If there were support for converting
>>>>>>>> them to groovy (do we even support groovy tests?), I'd be glad to help lead that change.
>>>>>>>>
>>>>>>>> and then, start with OFBIZ-5699?
>>>>>>>>
>>>>>>>> Regards,'Hans
>>>>>> That won't happen any time soon, I'll be dealing with the conversion to EntityQuery for the foreseeable future.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>
>>
>
>