Just to play 'devil's advocate' for a moment here... If we have unit tests run automatically each time we run 'mvn package', that means that *everyone* who installs DSpace 1.7 (once it is released) will be running these unit tests during the installation process (as our DSpace installation process includes the step to run 'mvn package').
So, in theory, I completely agree with Robin & Andrew's points that it should run every time you build DSpace. However, in practice, I'd have to disagree -- I wouldn't want every person installing DSpace to have to wait while all the unit tests are run (and perhaps get confused if certain unit tests report failures -- because of local customizations or an accidentally broken unit test). Until we are better able to separate out a development "build" process and a production "install" process, I think we likely should disable these tests by default. Developers should run them each time they build DSpace (or especially before checking in new code). But, we don't want users to need to run them each time they install or upgrade DSpace (though they will have the option of doing so, if they wanted to). As for the DCDate question, I agree with what Andrew has said. I think it's better to have a failing test which lays out the expected behavior of DCDate, than to have a succeeding test which replicates the failures of DCDate. If we find that the failure errors become too annoying, perhaps we should just comment out the DCDate testing altogether (as Andrew also suggests) until someone can spend the time to fix it. - Tim On 8/2/2010 8:00 AM, Andrew Woods wrote: > Hello All, > I agree with Robin in advocating for having the unit tests run by > default during the build. A successful, healthy build is one in which > the baseline not only compiles, but verifies compliance with the > contracts set forth by the unit and integration tests. If during > development, the developer wishes to disable tests for quicker cycles, > that option is available. > > In reflecting on the "Three Laws of TDD": > 1. You may not write production code until you have written a failing unit > test. > 2. You may not write more of a unit test than is sufficient to fail, > and not compiling is failing. > 3. You may not write more production code than is sufficient to pass > the currently failing test. > > ...it would seem that writing a test that lays out the expected > behavior of say DCDate (i.e. a failing test) is in order. If there is > no immediate intention of fixing DCDate to comply with the test, then > maybe commenting the offending test methods out with //FIXME notes > seems reasonable. > It is less clear to me why having a test that confirms the erroneous > behavior is useful, except that it could reveal when DCDate becomes > broken in a new way? > Andrew > > On Mon, Aug 2, 2010 at 6:18 AM, TAYLOR Robin<[email protected]> wrote: >>> 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' >>> --- >> >> My vote would be to default to 1) and people have to indicate if they don't >> want them run. >> >>> >>> --- >>> 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 >>> ........... 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. >>> --- >> >> +1. In the case of DCDate its already widely known that it is broken. Having >> the test there will help in fixing it. >> >> >> Cheers, Robin.. >> >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> >> ------------------------------------------------------------------------------ >> 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-tech mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> > > ------------------------------------------------------------------------------ > 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-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ 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
