Hi all, Apologies for emailing again - as pointed out to me by Keith, the correct SVN repository URL is incorrect in my email, but should be:
- http://scm.dspace.org/svn/repo/sandbox/gsoc/2010/testing/ (the URL below is for the 'trac' user interface version, not for the raw SVN repository version) Thanks, Stuart On 1/08/2010, at 3:13 PM, Stuart Lewis wrote: > Hi all, > > At last week's DSpace Development meeting it was decided that the GSoC > testing project is appropriate to be committed into 'trunk' so that it can > become part of DSpace version 1.7 which is due out before the end of the > year. As the mentor for the project, I work with the Pere Villega (the > student) to get the project ready for inclusion. > > The project is currently looking very good, and runs a lot of junit tests > across the code. The majority of the tests that have been created so far are > relate to the browse, content, and storage parts of the core API. The tests > are executed via maven. > > Before we merge Pere's branch into trunk, I'd like to ask for some opinions > from the community at large: > > --- > i) Should the tests run automatically every time the code is packaged? > - Maven tries to run tests when the 'mvn package' command is given. > Whilst this is a good thing to do (as it highlights any errors that are > present in that build), it does add an extra minute to the build time. This > doubles the time it takes to run 'mvn package'. There are two choices of > what to do here: > 1) Make the tests run automatically, and if you want to skip them, run > 'mvn -Dmaven.test.skip=true package' > 2) Make the tests optional, to run them type 'mvn > -Dmaven.test.skip=false package' > --- > > --- > ii) Some parts of DSpace are 'broken' right now. A good example is DCDate. It > has some issues, such as if the date is the 1st Jan, then it assumes the > granularity of the date is just a year. This is because if you just set a > year, it defaults to the 1st Jan. However, if you want a date of the 1st > Jan, it won't work. Therefore some of the tests for DCDate fail. Some of > the tests that have failed in other classes have been fixed as a result of > the testing. This is a good 'win' for the project as it is highlighting > errors for us already. However some classes such as DCDate need a lot of > work, and are already being reviewed by some members of the community. The > question is: > - Should we commit 'correct' tests that fail for DCDate, or should we > commit tests that are broken in the same way as DCDate is broken? Whilst it > is probably not good practice to commit incorrect tests, having tests that > are going to fail for a while (until DCDate is fixed) causes problems as it > means that builds will always fail. This is a side effect of introducing a > testing framework around buggy code, rather than having the framework come > first. My preference would be to commit the faulty test class, but to use a > Test Driven Development methodology for the re-development of DCDate to > ensure we get it right next time. > --- > > If you have an opinion about either of these, please express it so that we > can come to a consensus. > > Finally, a few people have had a look over Pere's code, but it would be great > for more people to check it before we merge it into trunk. It is very easy > to try: > > - svn co http://scm.dspace.org/trac/dspace/browser/sandbox/gsoc/2010/testing . > - mvn -Dmaven.test.skip=false package > > You should see the code compile, then an in-memory database will start up, > and some tests will be run. If you want to look at the tests, look in > dspace-test/src/test/java/org/dspace/ > > Many thanks, > > > Stuart Lewis > IT Innovations Analyst and Developer > Te Tumu Herenga The University of Auckland Library > Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand > Ph: +64 (0)9 373 7599 x81928 > Stuart Lewis IT Innovations Analyst and Developer Te Tumu Herenga The University of Auckland Library Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand Ph: +64 (0)9 373 7599 x81928 ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
