Hi all,
This is a quick reminder that hopefully sometime this week we will merge Pere's
Google Summer of Code 'testing' project branch into 'trunk' ready for version
1.7. To help with this, I have just merged trunk back into the branch, so that
the branch is up to date, which should mean
I have a couple of thoughts on this:
If local customisations cause previously-passing unit tests to fail,
those customisations have pretty much by definition broken the app.
That being the case, should the user then blithely install the broken
version of the app anyway? Alternatively, if
Hi,
I agree with Stuart, maybe it's good to disable the test by default in the
initial integration, and once there is good coverage for several classes we
enable them again?
Right now there may be changes to the code, structure that it's used by the
tests, etc... so maybe it's not good to
Also, I apologise to Stuart for choosing the wrong spelling of his
name. There's probably a moral in there somewhere. :)
--
Simon Brown st...@cam.ac.uk - Cambridge University Computing Service
+44 1223 3 34714 - New Museums Site, Pembroke Street, Cambridge CB2 3QH
On Tue, Aug 03, 2010 at 01:57:41PM +1200, Stuart Lewis wrote:
However, I think we need to be careful in drawing a distinction between the
ideal / correct answer, and the position that we are currently in. The
DSpace codebase has code that is over 8 years old, and this is our first
foray
Hi Andrew,
Good point. The only reason this separation of profiles hasn't
happened yet is that no one has expressed a need for it or thought to
implement it. Obviously, we've now discovered the need throughout these
unit testing discussions.
It does seem like a relatively easy way to better
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.
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
All,
I'll play 'devil's advocate' a bit more, based on Sands' good points.
On 8/2/2010 9:50 AM, Sands Alden Fish wrote:
- Maven is #1, a developer's tool, and #2, implements best-practices.
Changing the default behavior is implementing less-than-best-practices.
I agree that Maven is a
Hi again,
Thanks everyone for your feedback on these questions. As is evident from what
most people are saying, the correct answer is that tests should be run by
default, and we should only have correct tests which require the correct
behaviour. This can then work into the future with a TDD
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
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
12 matches
Mail list logo
