From: "David E Jones" <[EMAIL PROTECTED]>
On Nov 13, 2008, at 1:14 AM, Jacques Le Roux wrote:
Maybe, as David suggested, we could enforce our rules about that (no new
features without tests).
I'm afraid this would drastically reduce contributions. Maybe it's better to
have less but more robust.
I don't believe I've ever been in favor of enforcing a rule requiring new features to be accompanied by automated tests. In fact,
I think I've spoken/written against that a number of times.
I misunderstood this sentence then
<<Mobilize test contributors (testtools, selenium, etc), allow
separate people to be involved in contributing tests and contributing
features (don't require test submission, but if anyone wants something
to work in a certain way, they should submit a test for it as our
normal way of doing things)>>
This idea came also because some interesting patches are submitted without
sufficient informations on how to test them.
Maybe we could suggest in "How to create a Jira issue" (contributors best practises) to put either, some or all (depending on case)
of
(bugs)
. Detailled steps to reproduce
(New features, improvements)
. Add a separate testing patch (since it's likely that they have tested on their system so they have something we don't). This is
not something we will use later, only to faster main patch test.
Any other ideas welcome here...
Like you say, this may reduce contributions. The bigger issue with a community-driven project is that people are motivated by a
small number of things:
1. what they or their clients need (strong)
2. social pressure from others in the community (semi-strong)
3. desire for recognition (fairly weak)
4. desire to create something good/new (fairly weak)
A quick note on the strength of these motivations: I'm not trying to comment on human nature for all things that a person might
do, or that would apply to all people, but I am saying that for business-oriented software developed in a community-driven model
these seemed to be what drive actual quantities of hours and actual refinement of what is developed.
So, how do we get people to contribute tests? IMO it has nothing to do with new functionality, it has everything to do with how
people want OFBiz to work for them. In short the idea is that if someone wants something to keep working a certain way they
should contribute an automated test for it. It's really that simple, and goes to motivation #1.
To make it a stronger motivation, we can use motivation #2 as well. When people say "hey this doesn't work any more", or "it is
important that this always work this way" the response in the mailing lists can always be "great, submit an automated test!".
This allows people to invest in what they care about. Of course, to make this happen for real and not just seem like a good idea
we need the testing tools to be as easy and consistent as possible. It needs to be easy to create tests, and it needs to be easy
to run existing tests and to review what existing tests are and do. Those aren't easy features to implement. Because of these
we've discussed using Selenium because it is easy to record test sequenced that test everything from the client side UI code to
the database in and out. However, running these tests and creating suite of them that can run in an automated way that is
organized by component still needs to be done. Even more difficult, it seems right now, is that Selenium depends on some GPL/
LGPL libraries, so we can't include them all in OFBiz, which means that either the Selenium licensing is invalid (in the case of
GPL libraries Selenium would have to also be GPL licensed) or at least it is much more difficult to run the tests because we
can't include them in OFBiz.
-David
Selenium looks like a deadlock for us. The team never answered my questions. I think they don't care. Like a lot of people who are
not really understanding licence issues. Actually I believe most of them are uising GPL, that's why they don't care. Maybe also they
think it's not their job, and are only interested in code.
Jacques
