Maybe these differences are stemming from using tests for design, ala
TDD, which I am practicing while having Maven as my build tool. This
topic seems to be drifting towards more of a discussion regarding TDD.
I do want to use Maven for my development, and I like the way Maven
embraces practices in its core ( tests, single artifact, etc. ), so
this is interesting for me to see if this is yet another idea that
Maven should "embrace".
So, sorry for the off-topic, seemingly ranting response. Skip if
your not interested...
>>>>> On Thu, 30 Oct 2003 15:08:45 +0100, Michal Maczka <[EMAIL PROTECTED]> said:
> Jeffrey D. Brekke wrote:
>> Yes, I agree 100% with this "school of thought". I want the tests
>> to be fast and no external dependencies, even files. I treat the
>> need to fall back on external resources in programmer tests as a
>> potential code/design smell. Same with extensive/complex fixture
>> setup.
>>
>>
> I tend to disagree. The golden rule is "Tests should be as simple as
> possible". The speed of execution for me is also no
> issue. Optimization alomst always results in more ugly code which is
> more difficult to understand. Of course simplicity often means 100%
> of Java code, but I know situataionn when doing some things in Java
> Code is simply a bad choice.
Simple and fast. For me using a string to define something that could
exist in an external file is pretty simple and fast. I am not
promoting premature optimization of code, but I want my tests to be
very fast. Fast enough not to interfere with my rhythm as I develop,
otherwise I won't run them.
Case in point, we currently have 1,100 tests that run on each build.
In the past we haven't thought about speed of tests, relying on
external resources, etc. Our build is now at over 40 minutes. Who is
going to run through all the tests before committing, or even after
each change, when it takes 40 minutes?
> Say that you are tesing your HTTP or SMTP request parser. I think
> it's easier to prepare test data for the parser in external files.
> Specialy that is can be done by someone who knows SMPT/HTTP protocol
> but doesn't know Java. If parser of HTTP/SMTP requests is not
> complex enough - what about HTML or Java parser? Are you going to
> hardcode samples of HTML or Java files in your Java code?
I think that even in the parser examples small tests of behavior, even
with the snippets in the code, is simpler, faster, and less prone to
break.
But I could see an expert providing tests in the form you are
describing. They just might not be in the form I want for my tests.
Maybe they are not unit tests but more like customer tests?
> In such cases I always create samples in external files. Note that
> it's also easier to reuse such data in other similar projects.
Possibly a smell? I like my tests to be independent.
> For example in case of Maven - as for me it's OK for me to provide
> test samples of projects as XML files (POMs).
This may be more along the lines of customer testing. This feels more
like testing from the outside, further away from the code.
I try to get close to the code when I'm testing, then when one test
breaks, the resulting message will provide me with more focused
information on what is wrong. The further away from the code I test,
the less specific the results. TDD provides this closeness for me.
This (TDD) is where the desire for tests to rely on external resources
may be perceived as a smell.
jb
--
=====================================================================
Jeffrey D. Brekke [EMAIL PROTECTED]
Wisconsin, USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
