Wojtek,
Looks like you're asking for 2 things here: testability and extensibility.
Please note that my answers do not represent OFBiz community's, just my opinion.
For testability, you need documentation of OFBiz. At least functional docs. Such docs are really
sparse at the moment, so the issue of testability is rendered moot given the lack of this
prerequisite.
I would suggest you create your own set of test cases based on your own business logics. After
all, you want to test your customized OFBiz against your client's set of requirements, not the
OFBiz community's.
(At some point, perhaps even now, the community could be working to amass docs on OFBiz,
functionally speaking.)
For extensibility, I can just say 1 word: total. I've not seen anything as extensible as this.
Between the entity engine, the widget engine, and the tried-and-tested integration of Beanshell,
FOP, Freemarker, etc, OFBiz is a staggeringly large piece of "tutorial by example". Of course,
it's being opensource is also a major factor.
I would suggest you spend some time to get up to speed with the OFBiz framework, perhaps through
the training videos or buy some training seminars from the community. Once you get a "once
through" (end-to-end) tutorial, you'll be hooked on OFBiz.
(No, I do not provide such training seminars. I've never bought any training from the community or
undersun consulting. I've never been paid by anyone here. I took apart OFBiz myself like I would a
ham radio, but that's my personal preference to sweat things out myself big time.)
Jonathon
David E. Jones wrote:
Wojtek,
While it's great that Jacques has answered and shared his thoughts and
experience on this, please don't consider that a full representation of
the state of testing in OFBiz.
You should know that testing has been considered since day 1, but to
date I personally have not had a single client willing to sponsor any
sort of testing effort. Combine this with the fact that the framework is
made up mostly of business-level tools and we are fortunately in a place
where there are few low level bugs that require low-level unit tests. We
still definitely have a need for 2 things in the testing area:
1. regression testing for applications, mostly on the service level
(even if driven through the web-based UI)
2. tools and infrastructure in place for pre-development acceptance testing
Note that there is already a pretty good test infrastructure in place
and it is used right now to run the JUnit tests for various of the
framework components (mostly the entity and service engines). It just
needs to be extended to support easy execution of testing scripts
created by other tools. The main ones we are considering are Grinder and
Canoo WebTest.
Whether you use OFBiz or not is your choice and if it works well for
you, great, if not that's fine too.
A lot of people talk about testing, but so far little has been
contributed in this area, largely I think because it has always been a
nice to have, and no one with sufficient resources has invested
sufficiently in it. That's really all it comes down to. I developed the
current testing framework in the testtools component and while
functional for junit tests it is far from complete. I have nothing else
to invest in this as other obligations with higher priority won't allow
it, so help from others is, as with most things, necessary.
But yes, OFBiz is inherently testable and includes a great deal of
functionality for creating and automatically running sets of tests.
There are even nice tools built around the entity engine for adding data
to the database and asserting that the data in the database matches a
certain state.
-David
On Jan 15, 2007, at 3:45 AM, Wojciech Biela wrote:
Hello
I recently looked at ofbiz and am now evaluating whether or not we
should go with it or not. We are a software development company.
The key thing for me at this point is testability (both unit- and
functional-level). I have a great concern because I hear that only
recently people are starting to think about it on the ofbiz list, and
the project dates back to 2001, so there is a whole lot of legacy code
that is not tested in any (automated) way?
I read Cameron Smith's post from Nov 1 2006 "More on testing
framework" where he said that he had "Unit Tests proper - run as JUnit
tests", could any of you (or you Cameron) elaborate a bit about those
tests in the context of ofbiz
- how painful was it
- what components did you test
- what things did you mock
- what do you suggest
Unfortunately I didn't find this information in the documentation and
a preliminary google search on this subject didn't reveal any
revelations either. I only found that you are taking about functional
testing. But then I ask what about unit level tests? I see junit.jar
in the sources but I then again I see the build process does not
invoke unit tests (there is a separate ant task for it), I read that
there is a total of 24 unit tests.... There was some info that the
topic is covered in the advanced (commercial?) documentation by
Undersun, is there anything apache-licenced ;) on that?
Is the architecture of ofbiz testable or not ? Is it possible to write
unit test (i.e. isolated unit tests) as well as integration tests
(also through junit).
This is very important to me as we try to follow the Test-Driven
Development practice and thus testability is the key concern to me. I
like very much what you've done here, but I am afraid whether we will
be able to safely play around with it and alter it for our customer
without killing it.
Concerning functional and acceptance testing have anyone considered
using FitNesse, it's a really glamorous tool for holding acceptance
criteria and running them against the system under test, additionally
it's a great collaboration tool (it's a wiki). If you really really
(as in: you rarely should) need to check some things though the
browser interface then there are perfect examples of calling Selenium
from FitNesse if anyone is interested I may point you to such
materials.
This is especially important if you would like to clearly specify
functionality (define acceptance tests) ahead of implementing this
functionality, recording stuff with the Selenium recorder is more or
less fine for legacy stuff but that's not always the case.
BTW please tell me how hard will it be to degrade the process of
adding products, promotions to something simpler, our client wants
some specific bits of what I see in the demo app, so I'm thinking
about simplifying things for him as his main request is simplicity.
Wojtek Biela
www.exorigo.pl