Joachim Draeger wrote:
I can't see the advantage in accepting only passing tests.
The advantage is that each developer running tests and having a failing
test will know that he have to search for the problem in its local copy
and can skip the manual check of each "know failing test list".
What will happen when we'll have 423 failing tests and 613 passing? You
break something and they will be 424 failing and 612 passing: how do you
know what is the new failing one?? HOw do you rerun the only failing test?
I consider this as a limitations of our tools/workflow. Maybe there is
no practical solution.
I agree. But I work on james in a concrete way and not theoretically, so
I am +1 for everything that increase my productivity, -1 for everything
that decrease the productivity.
I don't care of a religious wars about how TDD works, how unit testing
works, and why the foo IDE is better than the bar tool.
I explained why I consider having all passing tests a *must*.
If the majority of committers prefer what you propose I will have to
change my way: if this change decrease my productivity but increase the
productivity of other committers I will of course accept it.
That does not necessarily mean every failing tests is a subject to
immediate fix. For example, this is not possible in
test-driven-development which is based on failing tests.
Would you accept failing tests used for TDD in James?
No, unless we start using TDD for james.
And if we decide to do this maybe we should define a different way:
separate test to be "solved" from the to be implemented one.
Right. That's a possibility to solve the "tool/workflow" issue. Maybe a
different TestSuite, a different test source folder or by naming of the
testclass. Ant would e.g. allow to ignore test classes that begin with
Future*.class or TDD*.class.
Well I don't want to start the TDD revolution right now. Another
possibility that came to my mind is committing TDD tests into sandbox.
They could be easily checked out and run from an IDE. (Eclipse:
"Required projects on the build path")
Joachim
Who is going to use TDD? How?
TDD has thousands of variations and any group using TDD has its own
pratices.
Let's talk about concrete things: are you going to use TDD? How do you
plan to work on it?
Once we have a list of committer working in a TDD way (or committer that
likes to have failing tests) we can decide how to coordinate our efforts
in order to optimize the work for everyone.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
