For my part, I think the choices here are obvious.
- Writing "broken" tests that will pass based on broken code amounts to
ignoring broken code and serves no good purpose. (Why include the test at all?)
and
- Maven is #1, a developer's tool, and #2, implements best-practices.
Changing the default behavior is implementing less-than-best-practices.
For #1, I mean to say that Maven is not a basic end-user's tool, and we
shouldn't make compromises based on a scenario that the tool wasn't designed
for. Don't the binary releases exist for for those who don't need to work at
the level of source code? Documentation (the same that would suggest an
inexperienced user run `mvn package`) could easily describe to the user why
they might want to run `mvn -Dmaven.test.skip=true package` instead.
As for #2, yes, we can recommend that developers should always include this
switch to run the tests, but the reason that it is default behavior in Maven is
because inevitably, people take short-cuts or forget to cover their bases, as
good as a community is at being comprehensive. I think this should stay as a
default, as it was intended.
--
sands fish
Software Engineer
MIT Libraries
Technology Research & Development
sa...@mit.edu<mailto:sa...@mit.edu>
E25-131
On Jul 31, 2010, at 11: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
------------------------------------------------------------------------------
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
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
------------------------------------------------------------------------------
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
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
