Hi, if I may join the conversation (I submitted the Enovation code). IMHO the approaches would be something like:
1) Unit testing. It's been mentioned to store these classes in a separate module (maybe I misunderstood). I would advise against it, Maven 2 project structure (the one used by Dspace) has a folder for testing (src/test) where one can put all test-related resources. That includes Java classes, resources and other. This can be used from Maven and other systems to run the tests. This tests are not supposed to be run by non-developers, and they should be in the same module as the source they are testing. In this area, we have to be aware the code of Dspace is not really testable as it violates the Law of Demeter quite often. I've read about the mock for Context, which would make it easier to build some tests, but as I mentioned in my JIRA ticket it would be advisable to consider some refactoring in the medium-long term, to improve the quality of the code. In fact could eb done as part of this year's GSOC now that 1.6 has been released. The sooner that's done, less effort will be involved :) 2) Functional/acceptance/regression testing. I completely agree with the proposal about using Selenium, in fact is probably the best tool for the job and would be useful to validate a vanilla installation of Dspace. The replacement of logic, as mentioned, should have little or no impact on the scripts as they use ID or names to identify the actions, so even layout changes should not affect them (in theory). 3) Behaviour testing. Another aspect we could consider for Dspace is Behaviour Testing. As explained here (http://blog.dannorth.net/introducing-bdd/) this could be considered an extension of Unit Testing, focusing more on the expected behaviour of a class than on creating test cases for each method. I find it more appealing to developers than unit testing, as you focus on the functionality, which means less tests (as several times a number of methods work together to achieve something) and reduced maintenance of unit tests when you change methods). Given the status of Dspace, with a lot of code already done and several dependencies among them, could be a way to provide testing for some classes. And if you want to go all experimental, you could use specs (http://code.google.com/p/specs/ for it, which offers some nice tools :) Best regards, Pere Villega Pere Villega Software Engineer, Enovations Solutions, The Friary, Bow St, Dublin 7 Direct +353 1 865 6472 Main : +353 1 602 4784 Fax: +353 1 865 6207 www.enovation.ie ***Winners of the 'Open Source Project of the Year' award at the ICT Excellence Awards 2008**** On Thursday 08 April 2010 16:38:25 Elliot Metsger wrote: > Thanks for the pointers Mark. The work that is there probably isn't > directly applicable as it is way behind the trunk at this point, but > the approach may be useful. > > I tried a couple of approaches, with varying degrees of success. One > approach was to modify core DSpace classes (e.g. adding protected no- > arg constructors) to support creation of mock objects for core classes > like Item and Context (the mock objects extended these classes e.g. > MockItem extends Item). Another approach was to use a combination of > JMockit (used to mock static methods) and EasyMock for creating > mocks. Note that JMockit instruments bytecode in order to mock > statics, so there is some maven pixie dust required for invoking > surefire (IIRC a dependency:copy and some system properties passed to > surefire). > > I think the JMockit/EasyMock approach worked better for me; I think > maintaining a library of mocks is more difficult. If you are doing > unit testing, a simple mock of Context is enough to make DSpace think > a database is there when it actually isn't. There is some work in one > of those branches which has a test harness for spinning up a database > and loading in seed data for full on integration tests. > > On Apr 7, 2010, at 6:58 PM, Mark Diggory wrote: > > 1.) We need to be clear about separating Unit Testing the codebase > > from kicking the tires of an installation. So, I rather like your > > separation for the test classes into a separate module. we do still > > need to think about true Unit testing and it should remain separate > > so please scratch my idea about using src/test/java. > > I agree its important to understand: there is a difference between > unit testing and integration testing, and that may impact how the > project or test classes are organized, and what approaches are taken... > > I think the testability of DSpace is pretty important and I'm glad > that this work by Scott and others is moving towards that goal! > > Best, > Elliot > > --------------------------------------------------------------------------- > --- Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
