using the trunk as a test bed

[BJ Freeman]

I see commits like the one I just commented on that says lets open this
so it can be tested.
The "do no harm" comes to mind
Now here is my full thoughts on this.
i think we have enough manpower at this point that we should require
that  a test unit be used for testing before submitting to the trunk.
then allow it to be committed along with the code that was tested by the
test unit.


--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

[David E Jones-3]

On May 30, 2009, at 4:22 PM, BJ Freeman wrote:

> I see commits like the one I just commented on that says lets open  
> this
> so it can be tested.
> The "do no harm" comes to mind

Is it the contents of the commit or the comment from Ashish that  
bothered you?

I'll agree that his comment ("Reason of enabling this new  
implementation is that we should get bugs in extensive testing and  
code will become more stable") was poorly phrased and sounds like a  
lazy approach to contributing things.

However, you could also interpret this a different way, and give him  
the benefit of the doubt as to intent and process: "Changing the  
default to the new implementation which now has more features than the  
previous one and has been tested in a development/testing environment;  
would appreciate collaboration on further development of this and  
welcome others to test it according to their requirements, and we'll  
be happy to work with them on making it work for them even if their  
requirements are different than the ones we are working from."

I might be interpreting this a little too generously, but without  
evidence to the contrary this is what I'm happy to believe.

What I have more of a problem with is things like "I didn't write  
this, I haven't tested it, but since not very people complain about  
Commit-Then-Review in it goes!" IMO the CTR pattern, especially for  
anything widely used, is generally pretty rude and not good community  
etiquette. Of course, that's my pet-peeve and I know that I have a  
hard time being "generous" with people when I see it... but unless I  
see something specific that causes a problem I usually try to refrain  
from commenting...

> Now here is my full thoughts on this.
> i think we have enough manpower at this point that we should require
> that  a test unit be used for testing before submitting to the trunk.
> then allow it to be committed along with the code that was tested by  
> the
> test unit.

The project technically has zero manpower... it's all volunteer. That  
means that if no one cares enough about testing to work on it and  
contribute (and/or improve) automated tests then there won't be any  
tests. However things turn out, the management of the project is based  
on "meritocracy."

There are lots of different ways of approaching automated tests (and I  
say "automated" and not "unit" because it would be great to have a  
wide variety of automated tests and not just unit type/level tests).  
At this point we have pretty good support for automated unit tests  
(basically service level and below), but not such good support for UI-
level tests, though these are definitely getting closer.

Anyway, at the conference last year in New Orleans a number of ideas  
and approaches were discussed (and I think all of these have been  
discussed over time on the mailing lists too). The one I like the  
most, and that I've mentioned on this mailing list, is to encourage  
people that want to have a certain thing work a certain way to  
contribute an automated test for that. In some cases people who  
contribute automated tests will be the same as those who develop  
things, and probably in many cases it will be people who were not  
involved in the development.

The basic idea is simple: if you want something to work a certain way,  
contribute an automated test that verifies it; if you manage to get  
your unit test committed then you have an easy basis to complain that  
something is broken, and you have a "foot in the door" for making  
OFBiz function the way YOU want it to.

-David

[BJ Freeman]

I apologize to Ashish that I chose his to make a stand on.
I was not meant to be a personal attack on him.
it was the statement only that triggered it.
I dislike being a unwilling guinea pig.
and I dislike debugging some else's code because they have not.

now if someone has tested and thinks they have the bugs out, that is
different. But I see in the commits a lot of changes becuase error are
found.

BTW this is not the first time i have mentioned this. Actually I started
 this back in 2003.

yes you have brought it up also.

even had a lively discussion about testing.

as you may have noticed I don't demand things work a certain way
I may express an opinion. I used to offer to put the things in, incase
someone wanted to use them,  but I do the things I want, the way I want,
on my own version.
and yes i do testing all the time, it runs day after day after each change.




David E Jones sent the following on 5/30/2009 6:01 PM:

>
> On May 30, 2009, at 4:22 PM, BJ Freeman wrote:
>
>> I see commits like the one I just commented on that says lets open this
>> so it can be tested.
>> The "do no harm" comes to mind
>
> Is it the contents of the commit or the comment from Ashish that
> bothered you?
>
> I'll agree that his comment ("Reason of enabling this new implementation
> is that we should get bugs in extensive testing and code will become
> more stable") was poorly phrased and sounds like a lazy approach to
> contributing things.
>
> However, you could also interpret this a different way, and give him the
> benefit of the doubt as to intent and process: "Changing the default to
> the new implementation which now has more features than the previous one
> and has been tested in a development/testing environment; would
> appreciate collaboration on further development of this and welcome
> others to test it according to their requirements, and we'll be happy to
> work with them on making it work for them even if their requirements are
> different than the ones we are working from."
>
> I might be interpreting this a little too generously, but without
> evidence to the contrary this is what I'm happy to believe.
>
> What I have more of a problem with is things like "I didn't write this,
> I haven't tested it, but since not very people complain about
> Commit-Then-Review in it goes!" IMO the CTR pattern, especially for
> anything widely used, is generally pretty rude and not good community
> etiquette. Of course, that's my pet-peeve and I know that I have a hard
> time being "generous" with people when I see it... but unless I see
> something specific that causes a problem I usually try to refrain from
> commenting...
>
>> Now here is my full thoughts on this.
>> i think we have enough manpower at this point that we should require
>> that  a test unit be used for testing before submitting to the trunk.
>> then allow it to be committed along with the code that was tested by the
>> test unit.
>
> The project technically has zero manpower... it's all volunteer. That
> means that if no one cares enough about testing to work on it and
> contribute (and/or improve) automated tests then there won't be any
> tests. However things turn out, the management of the project is based
> on "meritocracy."
>
> There are lots of different ways of approaching automated tests (and I
> say "automated" and not "unit" because it would be great to have a wide
> variety of automated tests and not just unit type/level tests). At this
> point we have pretty good support for automated unit tests (basically
> service level and below), but not such good support for UI-level tests,
> though these are definitely getting closer.
>
> Anyway, at the conference last year in New Orleans a number of ideas and
> approaches were discussed (and I think all of these have been discussed
> over time on the mailing lists too). The one I like the most, and that
> I've mentioned on this mailing list, is to encourage people that want to
> have a certain thing work a certain way to contribute an automated test
> for that. In some cases people who contribute automated tests will be
> the same as those who develop things, and probably in many cases it will
> be people who were not involved in the development.
>
> The basic idea is simple: if you want something to work a certain way,
> contribute an automated test that verifies it; if you manage to get your
> unit test committed then you have an easy basis to complain that
> something is broken, and you have a "foot in the door" for making OFBiz
> function the way YOU want it to.
>
> -David
>
>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

[Ashish Vijaywargiya-5]

Hello BJ,

FYI we have done extensive testing before making the Java Code as the default option.
Total of 5 members were involved in this process. Here are my thoughts:

1) While committing the code, the exact rephrased word was there in my mind. My bad I wrote it in not a good way.

--------------------------------------
However, you could also interpret this a different way, and give him the
benefit of the doubt as to intent and process: "Changing the default to
the new implementation which now has more features than the previous one
and has been tested in a development/testing environment; would
appreciate collaboration on further development of this and welcome
others to test it according to their requirements, and we'll be happy to
work with them on making it work for them even if their requirements are
different than the ones we are working from."
--------------------------------------

Thanks David for making it more clear.
I agree that it depends on the individual how he / she interpret the things.
If you are watching the progress or reviewing the work coming on the way then only you can comment on the things to get improved results.
Although comments coming on the other hand creates confusion and waste the time of each individual IMO.

2) In my log I mentioned a word "Extensive". What does it mean? It means we have tested it and we would be thankful to have help from others to review and comment on the work. At the same time we should continue our testing in more different different way. You won't believe but I had thought about this single word "Extensive" three or four times before committing the code.

3) We have only reused the things in Google Checkout. Like we have called helper methods, services etc.
We haven't made any changes in the Existing artifact of other components.
Before committing the code we found that there were no build fail and there were no functionality break .

4) I will wait for the three negative vote on my last commit to make the Java based implementation as the default option.
For a moment we have negative vote. And if we get two more vote then I will revert my changes.

If we talk about collaboration then few questions are coming in my mind that I would like to ask from you BJ.

-- How many times do you think that your reply contains good enough details for a person to move in a right direction instead of deviating each individual here or there?
-- How many times you read your email before posting it on the mailing list?
-- How many times do you think that your email would be well understood by someone in a first pass?
-- How many times do you think that the email written by you is properly formated?

I assure you all that in future I will think more and more before writing anything in the commit logs.

--
Ashish



BJ Freeman wrote:

I apologize to Ashish that I chose his to make a stand on.
I was not meant to be a personal attack on him.
it was the statement only that triggered it.
I dislike being a unwilling guinea pig.
and I dislike debugging some else's code because they have not.

now if someone has tested and thinks they have the bugs out, that is
different. But I see in the commits a lot of changes becuase error are
found.

BTW this is not the first time i have mentioned this. Actually I started
 this back in 2003.

yes you have brought it up also.

even had a lively discussion about testing.

as you may have noticed I don't demand things work a certain way
I may express an opinion. I used to offer to put the things in, incase
someone wanted to use them,  but I do the things I want, the way I want,
on my own version.
and yes i do testing all the time, it runs day after day after each change.




David E Jones sent the following on 5/30/2009 6:01 PM:
  

On May 30, 2009, at 4:22 PM, BJ Freeman wrote:

    

I see commits like the one I just commented on that says lets open this
so it can be tested.
The "do no harm" comes to mind
      

Is it the contents of the commit or the comment from Ashish that
bothered you?

I'll agree that his comment ("Reason of enabling this new implementation
is that we should get bugs in extensive testing and code will become
more stable") was poorly phrased and sounds like a lazy approach to
contributing things.

However, you could also interpret this a different way, and give him the
benefit of the doubt as to intent and process: "Changing the default to
the new implementation which now has more features than the previous one
and has been tested in a development/testing environment; would
appreciate collaboration on further development of this and welcome
others to test it according to their requirements, and we'll be happy to
work with them on making it work for them even if their requirements are
different than the ones we are working from."

I might be interpreting this a little too generously, but without
evidence to the contrary this is what I'm happy to believe.

What I have more of a problem with is things like "I didn't write this,
I haven't tested it, but since not very people complain about
Commit-Then-Review in it goes!" IMO the CTR pattern, especially for
anything widely used, is generally pretty rude and not good community
etiquette. Of course, that's my pet-peeve and I know that I have a hard
time being "generous" with people when I see it... but unless I see
something specific that causes a problem I usually try to refrain from
commenting...

    

Now here is my full thoughts on this.
i think we have enough manpower at this point that we should require
that  a test unit be used for testing before submitting to the trunk.
then allow it to be committed along with the code that was tested by the
test unit.
      

The project technically has zero manpower... it's all volunteer. That
means that if no one cares enough about testing to work on it and
contribute (and/or improve) automated tests then there won't be any
tests. However things turn out, the management of the project is based
on "meritocracy."

There are lots of different ways of approaching automated tests (and I
say "automated" and not "unit" because it would be great to have a wide
variety of automated tests and not just unit type/level tests). At this
point we have pretty good support for automated unit tests (basically
service level and below), but not such good support for UI-level tests,
though these are definitely getting closer.

Anyway, at the conference last year in New Orleans a number of ideas and
approaches were discussed (and I think all of these have been discussed
over time on the mailing lists too). The one I like the most, and that
I've mentioned on this mailing list, is to encourage people that want to
have a certain thing work a certain way to contribute an automated test
for that. In some cases people who contribute automated tests will be
the same as those who develop things, and probably in many cases it will
be people who were not involved in the development.

The basic idea is simple: if you want something to work a certain way,
contribute an automated test that verifies it; if you manage to get your
unit test committed then you have an easy basis to complain that
something is broken, and you have a "foot in the door" for making OFBiz
function the way YOU want it to.

-David