Joachim Draeger wrote:
I'm still not
convinced about the benefits except they are circumstancing limitations
in current tools.
When we'll have tools without that limitations we maybe change our minds
;-) In the mean time I think that tools matters.
Remove tools from the world, and you will find people to change their
behaviours.
Unit tests can be part of the definition. They should not be changed in
any way as long they are valid.
Not agreed. This is a too dogmatic point of view.
Maybe. But I noticed that they help me a lot as a "definition" in the
part-time os developer job. What does the code I started writing last
week?
My suggestion is to keep them local, or ask to use your own branch if
you need this.
Other tests, of course, for example integration or compliance test
could take much more time.
Right. As I started to test which IMAP commands work in the current
implementation I wrote integration tests. These have proven to be very
useful.
If the problem arises, that they are to slow for "every-day-use" we
should separate, but not change them.
integration tests don't belong into a unit test suite.
per definition, in java, unit tests test (more or less) a single class
("the unit").
What do you mean by that statement related to current James development?
Separating integration from unit tests? Don't use junit for integration
tests?
Joachim
Here the full suite take almost 1 minute to run. I think that while we
are under 2-3 minutes we can keep them together.
We probably don't have a single real unit test in our test suite if we
use some strict definition of unit test. But imho this is not important
now. I think the current tests are useful, and I don't care to find a
proper name for them.
When we'll have enough test to loose too much time testing I will be
happy to offer my time to split them or to optimize them.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
