On 17/06/2016 5:19 AM, Jacques Le Roux wrote:
Le 16/06/2016 à 22:53, Ron Wheeler a écrit :
One of the side benefits of having a small number of committer's is
that you prevent bad designs and poorly tested code getting into the
trunk.
The disadvantage is that the committers are easily overwhelmed by an
active contributor community.
Would you say that with 31 committers (most active) we are currently a
small number of committers?
Are the committers able to verify the code committed?
How many of the regressions should have been detected before the code
was committed?
How many of the regressions were caused by lack of documentation of
existing features so that people broke things that were "hidden"
relationships?
It is hard to build and maintain a bullet-proof integration test suite
so human engineering is still a big part of the solution.
You may want to put in some rules about unit tests so that code
without adequate test coverage can not be updated until the unit
tests are sufficient for the committer to feel confident about
accepting it. This may cause people to work on tests for stuff that
they did not write but are considered key functionality in the
modules being updated.
There is no free ride and if you allow people to build up the
technical debt of the project in order to meet their own deadlines,
you will eventually have to face a large debt that comes due.
Taher is paying off the debt in the framework which is a great
contribution.
It may be that others are going to have to take up the challenge in
the application side.
You may have to have a short moratorium on enhancements until the
debt is reduced to a manageable level.
There may also be the issue of people modifying too many layers at
once so changes affect a lot of different services so unpleasant
side-effects are easier to generate.
Are the regressions caused by a small group of contributors or from
updates going through a few committers?
As I said it's recently fortunately small things. For now it's hard to
answer to your question, because the HW effort is rip-roaring. I guess
when it will settle a lot of things will be better/fixed, in the
meantime me will certainly face some uncertainty.
My question was not about pointing finger put how to prevent issues.
Hence my question about Selenium because our current set of tests is
obviously not enough.
Your suggestion about more unit tests and rules is certainly to
consider. I'd wait the end of the rip-roaring HW effort, for things to
stabilise, and then try to introduce more constraints, or should we
discuss it right away, community?
When you are in a hole, the first think to do is to stop digging!
It is an open source project so there has to be some sensitivity
about asking people to do a bit more to clean up old debt but if that
is a problem and it is not addressed, it can be a big mess.
I see a lot of skilled good will and clearly success for the last few
years. I think we can achieve it, OFBiz is here to stay!
Jacques
Ron
On 16/06/2016 3:48 PM, Taher Alkhateeb wrote:
Hi Jacques,
Selenium tests cannot be unit tests in OFBiz because it requires
firing up
the server. You can consider them part of the integration tests
(existing
functionality). In fact, I would consider selenium tests to be
functional
tests (higher than integration) ->
https://en.wikipedia.org/wiki/Functional_testing
So yeah we can add them, but I don't think we can do that to the raw
unit-tests (at least in the context discussed in the other proposal
thread)
Taher Alkhateeb
On Thu, Jun 16, 2016 at 10:40 PM, Jacques Le Roux <
[email protected]> wrote:
Hi,
With the considerable HW effort, a lot of things are going on
recently,
and it's hard to follow. I though noticed that we experience more
and more
regressions (not all related to HW effort, far from it).
Fortunately it's so far mostly minor points and often related with
the UI,
OFBIZ-7346 and OFBIZ-7363 being counter examples (OFBIZ-7346 can be
critical)
From my experience, w/o a QA person or team, it's very hard to detect
those side effects at the UI level when you refactor or fix it. I
remember
the (ex) Neogia team (mostly Erwan) tried to maintain a
Selenium/Webdriver
set of tests. I don't know if they continue/d.
Since we spoke about Junit and unit tests recently, some prefer
TestNG, at
least coupled with Selenium http://testng.org/doc/selenium.html
Does it make sense, do you think it's only an utopia?
Thanks
Jacques
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
