I'm too suggestible, I always agree with the last emailer, however... > 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).
My fear is that if the tests are turned off by default then it wont be long until code is committed that breaks the test and they fall into disuse. So I guess it's a question of which is the lesser evil. > > 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. > Personally I just want any test in place. It will need rewritten along with DCDate but in the meantime it would be an aid in debugging. Cheers, Robin. > - 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<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-tech mailing list > > dspace-t...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/dspace-tech > -- 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-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
