Hello David
You should know that testing has been considered since day 1,
considered as in "it would be fun to have it" or "let's decouple this from that so we'll be able to test that in isolation"?
but to date I personally have not had a single client willing to sponsor any sort of testing effort.
hmmm, funny, I'll tell you how it looks like from where I stand, it's a bit off-topic but never mind. Don't consider it offensive please (!), I just want to share. When I tell the customer whether or not he wants tests in place (acceptance tests) and talk for a quarter about the consequences of not having such test he always is more than happy to have those tests, and is even willing to help specify (or at least sign off) those tests. As for programmer tests (unit tests) they're non-negotiable for me, it's just part of programming, period. I just want to sleep well, once I got used to them I just can't do without them, it's like heroine (although I never tried the latter :) just seen the movies)
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.
true, if we plan to freeze that code and don't plan to refactor, smoke tests (e.g. acceptance tests, business level tests) are not too good as they just tell you, something went wrong, where unit tests tell you this method here doesn't return a correct value. That said I know right now covering ofBiz with unit tests just like that is insane and smoke tests are the only acceptable solution for the moment.
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)
true
2. tools and infrastructure in place for pre-development acceptance testing
pre-development acc testing, I don't get it, please elaborate
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).
24 tests (as you outlined on the mailing list a while ago)?
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.
please consider also Selenium, or better Selenium RC ran from FitNesse, just take a look at it, if you want I can elaborate on both
Whether you use OFBiz or not is your choice and if it works well for you, great, if not that's fine too.
as in: "I don't care"? :))) no offence, yeah I know, I really hope it works well, we are starting the bidding process in a few days so it'll be the client's decision if we are to do it or not
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 know exactly what you mean.
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.
I can't say I will, because I'm not sure if the client will choose us, nevertheless for the time I am happy to discuss
But yes, OFBiz is inherently testable and includes a great deal of functionality for creating and automatically running sets of tests.
see? that's what makes me happy :) you should have started with that :)
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.
cool thanks a lot David! regards Wojtek
-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
-- Wojtek Biela
