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 <robin.tay...@ed.ac.uk> 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 > dspace-t...@lists.sourceforge.net > 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 Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
