On Mon, 28 Nov 2011 11:46:27 +0100, Emilis <[email protected]>
wrote:
Thanks, Jan, for the link. I actually didn't know about theories.
Fabrizio, could you provide an example where it is advantageous to
know that a specific test failed? When the test fails you can look at
the trace and find out the problem. If tests would be separate, I
agree it would be faster/easier to locate the issue, but does it
outweigh the redundancy that you get by having similar test methods?
In my experience I spend more time adjusting test cases due to code
changes as opposed to tracking down failing tests.
Your point make sense and rather than an example of the test, one would
need a complete example of the context (e.g. what you're going to deliver,
etc...).
But I try. Let's suppose the similar failed tests are two very similar
features but with a slight customization for two different customers.
Let's suppose I have to release to both customers next week. It's
important to know whether there's a problem with both, so I can't release,
or I'm going to release with a bug, etc..., rather than being able to have
the release at least with one.
Trying to make a generic rule of thumb, the granularity of tests (and now
I'm not going into details about unit/integration/functional, but for
simplicity I assume that a failed integration test will cause the failure
of a function) should match the granularity of delivery. I don't know
whether I was clear enough.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
[email protected]
http://tidalwave.it - http://fabriziogiudici.it
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
