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?
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?
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
