Hi Mathieu,
[snip]
Then I see no problems doing that and having already Minilang tests
present. We "just have" to drop Minilang tests when Groovy ones are
ready.
What I'm missing?
The problem I see is that if the people proposing the patches are not
willing to do the migration work right now, I see no reason why they
would want to do it afterwards when there will be no incentives to do
so.
Could be indeed
If we apply those patches as they are, then the rest of us will
eventually have to understand/maintain/debug them when they fail. Given
the current sad state of OFBiz integration tests we cannot afford to let
more “stuff to be cleaned up later” enter the codebase.
I see your point, you kinda expect people having created Minilang test patches
to convert them themselves. Not sure that will we work.
If I get empathic (something I easily do when reviewing) I can understand the
frustration of those people.
They create a patch before the decision is made and bam, it's no good :/
So it does not help to "put the blame" (OK I emphasise a bit here ;)) on them
Also we can't even rely on an expectation they will do the work. Some people
come and go...
Anyway at some point someone will have to do it
And at least, I believe it's better to inspire from those patches than to start
anew
To explain my hard feeling regarding OFBiz integration tests. I find
them really hard to understand/debug due to the following points:
- Logs are unreadable! I mean understanding which test has failed is
already an endeavour.
Oh that! I never look at integration test logs, it's impossible indeed.
I simply look at the result of the tests where the error logs are.
- The global nature of the data loaded during the tests makes things
brittle. We saw a lot of that in previous weeks where tests were
succeding when having both the framework and the plugins but failing
when having only the framework.
- People tend to be confused between integration and unit tests,
resulting in integration tests written in an atomic way which is not a
good thing. For example for testing services manipulating an
hypothetical entity ‘foo’, we would have a ‘testCreateFooService’ that
adds some stuff in the database and ‘testUpdateFooService’ that
retrieve the stuff added by the other. This is bad since it
introduces a order dependency between those tests. Instead of small
integration tests we should have bigger independant ones following a
scenario with multiple asserts.
Makes totally sense, unfortunately with 1300+ tests [1] I don't expect that to
happen soon
[1] https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/
Sorry for being long but I wanted to make clear that this is a real
issue.
Thanks for expression your opinion, that helps!
After 3 days, only people against expressed their opinions, so I think the
discussion is closed.
Jacques
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org
