I personally do not think this is a silly thing to do. I document everything.
even tests! Especially since I am in a large company setting, if the next guy
comes along at looks at my tests, he can see some of the comments I have made.
Maybe not make some of the same mistakes. etc... It is never, ever, a bad idea
to document.


"J. B. Rainsberger" <jbrains@...> wrote:
>So said icepickorama on 2003-06-30 --------------------
>Hi,
>
>Does anyone know of an existing tool or method one could use to
>generate a report of unit tests in a source file?  I find that I
>usually write my unit tests (using JUnit of course) and then I create
>another document which duplicates a lot of the comments that already
>exist in my test code (essentially each test has a description of
>what's being tested).  I think it would be incredibly useful if there
>were a way to generate these automatically, maybe using javadoc tags?
>Has anyone seen or used something similar?

A silly question: why are you writing comments describing what the test does?
Doesn't the source code already say that?


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603


Yahoo! Groups Sponsor
To unsubscribe from this group, send an email to:
junit-unsubscribe@yahoogroups.com


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

[Non-text portions of this message have been removed]

--- In junit@yahoogroups.com, "Erik Mattsson" <erik.mattsson@i...> wrote:
> Hi
>
> It all depends on how you build your code. There is no problem
> of having different source code for testing and real code

Yes, it comes down to policy and convienence.

> (does anyone have a Good name for "real code").

production code
application code
domain code
business code

> The things you need to do when having different folders is to
> first compile the source to one folder, and then compile the
> testcases into the same folder. Then theres no problem running
> the tests, and everything is seperated. (most IDE can handle
> different source folders)

I generally find it more confusing to use multiple source trees.

> We have the following folder hierarchy.
> project
>  - build - all .class files and other temporary files goes here.
>  - dist - all jar files and other distributable files goes here
>  - src - source folders
>    - main - main source (the real code, it needs a better name)
>    - test - all test sources
>    - doc - all documentation that is not automated (no javadoc)
>    - etc - configuration stuff

> It works fine, but could need some improvement.

I'd pull doc & etc out of the src dir.  I also tend to have a design
dir for Together to put its artifacts in.

Dave

--- In junit@yahoogroups.com, Dale DeMott <ddemott@y...> wrote:
> Would there be any way to use MockObjects to remove
> the dependence ?

Good call, Dale.

I expect there is.

Dave

--- In junit@yahoogroups.com, Michael Orozco <orozcom1@y...> wrote:
> I personally do not think this is a silly thing to do.

I do.  JB does.  We're not alone.

> I document everything. even tests!

Why?  What would happen if you didn't?  How much time is wasted by
writing & maintaining those comments?

Do you program by intention?  Why isn't your code written to express
what it does, what your intent was when you wrote it?  Why do you need
to write that separately?

> Especially since I am in a large company setting, if the next guy
comes along at looks at my tests, he can see some of the comments I
have made.

Wouldn't it be better if they could just look at the code and see what
it does.  If they can do that, then what use are the comments?

How do they know the comments are up to date?

> Maybe not make some of the same mistakes. etc...

If something is done a certain way for a reason (e.g. performance
tuning, using a specific algorithm, etc.) then a short comment is
reasonable.

> It is never, ever, a bad idea to document.

Yes, quite often it is.  If you feel the need to write a comment,
consider refactoring the code to make the comment unneccessary.

All this has been said in amany place by many people.  I suggest you
read "Refactoring" by Martin Fowler and my new book "TDD: A Practical
Guide".

That said there are valid times to document if it has value to the
customer or is needed/reasonable to set up for the next game (e.g.
"maintenance").

Dave

ps.  I'm thinking about writing a book on programming by intention.
Comments?  feedback?

Check it out....
http://www.amazon.com/exec/obidos/ASIN/1930110995/damurah-20


---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

[Non-text portions of this message have been removed]

>So said Dave Astels on 2003-07-02 --------------------
>--- In junit@yahoogroups.com, "J. B. Rainsberger" <jbrains@r...>
>> Long test method names with a common prefix means you should
>consider "factor out test fixture". :)
>
>You don;t need long names for that.. the prefix is the smell.

A fine point.


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603

>So said Kevin Baynes on 2003-07-02 --------------------
>
>I'm creating a textui.TestRunner with a PrintStream that writes to
>file. I can write to the PrintStream, but TestRunner keeps printing to
>the stdOut. Any ideas why it's not printing anything to the file?
>
>// construct TestRunner to output all results to our log file
>junit.textui.ResultPrinter printer = new junit.textui.ResultPrinter(out);
>junit.textui.TestRunner    runner  = new junit.textui.TestRunner(printer);
>runner.run(suite());

When you looked at the source for JUnit, what did you find out?

:)


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603

>So said Michael Orozco on 2003-07-03 --------------------
>I personally do not think this is a silly thing to do.

I'm pretty sure I said the QUESTION was silly, and not the act of documenting
the tests.

>I document
>everything. even tests!

Question: Who reads this documentation? Why? When? How often?

>Especially since I am in a large company setting,
>if the next guy comes along at looks at my tests, he can see some of the
>comments I have made. Maybe not make some of the same mistakes. etc... It
>is never, ever, a bad idea to document.

I love you like a brother, but this last statement is a howler.

In a large company setting, you may find it useful to provide high-level
documentation, such as a roadmap to the system or a description of its metaphor;
however, it is *always* a bad idea to document if no-one is reading the
documentation. If you don't know who your audience is and you don't have proof
that such an audience even exists, then producing documentation for that
fictitious or non-existent audience is generally a waste of time and energy. One
exception: if you benefit the act of writing documentation, and if that benefit
is not as easy to come by another way, then do document whatever you need to
document.

A top time-waster on software projects is writing useless documentation instead
of clear code.

Take care.

PS: Yes, I've worked on a project where no external documentation was required.
When a new employee came on board and began working with the code, he said,
"This code is so easy to read, I already understand what's going on." Since I
also benefitted from the easy-to-read code while I was building the system, the
effort I put into making the code self-documenting was well worth it. In other
words, if the code tells the story, then that is often enough.


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603

>Wouldn't it be better if they could just look at the code and see what
>it does.  If they can do that, then what use are the comments?

When do I find documentation usefull:
Often a programmer switches from one to another business domain. If he doesn't
understand a business domain, it can be quite hard for him to understand the
intent. I find documentation on business domain and the way it was abstracted
into code usefull. Documenting the business is not really a programmer's job,
but you will often find a situation where such documentation is non existent.
Also, documentation on larger scale solutions, architecture, patterns can also
be usefull to communicate the intent, because it is much more difficult to
understand and get "the bigger picture" from code.

Regards,

Danijel

> -----Original Message-----
> From: Danijel Arsenovski [mailto:darsenovski@...]
>
> When do I find documentation usefull:
> Often a programmer switches from one to another business
> domain. If he doesn't understand a business domain, it can be
> quite hard for him to understand the intent. I find
> documentation on business domain and the way it was
> abstracted into code usefull.

Good point.  I work at an HRMS/HR Portal provider company.  Domain knowledge
even across apps within the same overall business domain (e.g., benefits
enrollment vs. compensation planning, or business rules relevant to filling out
a w4 online vs. adding a dependent) can be spread across quite a breadth of
knowledge.

> Also, documentation on larger scale solutions, architecture,
> patterns can also be usefull to communicate the intent,
> because it is much more difficult to understand and get "the
> bigger picture" from code.

Yes, especially if you don't name things with the names of the patterns they
implement.  That is, putting on your design pattern hunter hat is more of a pain
than if someone documents (in names or in comments) that a class is some kind of
Registry or Observer or ServiceLocator, etc.

Scott Stirling
Workscape, Inc.

> -----Original Message-----
> From: J. B. Rainsberger [mailto:jbrains@...]
> Sent: Thursday, July 03, 2003 11:29 AM
> To: junit@yahoogroups.com
> Subject: Re: [junit] Unit test java documentation
[snip]
>
> A top time-waster on software projects is writing useless
> documentation instead of clear code.

I would agree that useless documentation is worse than clear code, but then
useless documentation is probably worse than messy code (as long as the code at
least works). However, I disagree with the statement - unless you got something
other than your own experience to back that statement up with.


> PS: Yes, I've worked on a project where no external
> documentation was required. When a new employee came on board
> and began working with the code, he said, "This code is so
> easy to read, I already understand what's going on." Since I
> also benefited from the easy-to-read code while I was
> building the system, the effort I put into making the code
> self-documenting was well worth it. In other words, if the
> code tells the story, then that is often enough.

This paragraph I really disagree with. I have walked into far too many shops
where the programmers produced code that they thought was easy to read, but in
fact wasn't. Just because it is "clear code" to you and possibly your team -
doesn't mean that it will be looked upon as "clear code" by the people that
follow you.
	 Frankly having a new employee walk in the door and comment how "easy the code
is too read" isn't that amazing or even points to the fact that the code is in
fact easy to read. He they know you favor "easy to ready code" they might have
been just saying that to get a positive response or to push up their own
capabilities in your eyes. Sure, your code could in fact be the most readable
code in existence, but a new employee pushing a positive response is not a good
indicator - its simply human nature.



Chip
-----
Programming: Its not just a job - its an indenture

--- In junit@yahoogroups.com, "Danijel Arsenovski" <darsenovski@a...>
wrote:

> When do I find documentation usefull:
> Often a programmer switches from one to another business domain. If
> he doesn't understand a business domain, it can be quite hard for
> him to understand the intent. I find documentation on business
> domain and the way it was abstracted into code usefull. Documenting
> the business is not really a programmer's job, but you will often
> find a situation where such documentation is non existent.

That's the idea of "metaphor" or "ubiquitous language" or "shared
vocabulary" from XP.

> Also, documentation on larger scale solutions, architecture,
> patterns can also be usefull to communicate the intent, because it
> is much more difficult to understand and get "the bigger picture"
> from code.

Yes, and that is a prime use of patterns (and for eg. UML): for
explaination.

Dave

>So said Chip Dunning on 2003-07-03 --------------------
>> -----Original Message-----
>> From: J. B. Rainsberger [mailto:jbrains@...]
>> Sent: Thursday, July 03, 2003 11:29 AM
>> To: junit@yahoogroups.com
>> Subject: Re: [junit] Unit test java documentation
>[snip]
>>
>> A top time-waster on software projects is writing useless
>> documentation instead of clear code.
>
>I would agree that useless documentation is worse than clear code, but
>then useless documentation is probably worse than messy code (as long as
>the code at least works). However, I disagree with the statement - unless
>you got something other than your own experience to back that statement up
>with.

You disagree with what part: that it's a time waster or that it's a "top time
waster"?

As for "something other than your own experience to back that statement up
with", what on Earth is more important than one's experience?

>> PS: Yes, I've worked on a project where no external
>> documentation was required. When a new employee came on board
>> and began working with the code, he said, "This code is so
>> easy to read, I already understand what's going on." Since I
>> also benefited from the easy-to-read code while I was
>> building the system, the effort I put into making the code
>> self-documenting was well worth it. In other words, if the
>> code tells the story, then that is often enough.
>
>This paragraph I really disagree with.

Since I documented my personal experience in this paragraph, I scarcely
understand how you can disagree with it. How does one "disagree" with
experience? Is that even defined?

Now if you disagree with the final statement, then do you have something other
than your own experience to back that statement up with?

> I have walked into far too many
>shops where the programmers produced code that they thought was easy to
>read, but in fact wasn't. Just because it is "clear code" to you and
>possibly your team - doesn't mean that it will be looked upon as "clear
>code" by the people that follow you.

There are certain objective measures of code clarity. You cannot possibly argue
that clarity is *entirely* subjective. We can even define clarity in terms of
clarity to the general population, as opposed to clarity to an individual, if
you like.

>      Frankly having a new employee walk in the door and comment how "easy
>the code is too read" isn't that amazing or even points to the fact that
>the code is in fact easy to read. He they know you favor "easy to ready
>code" they might have been just saying that to get a positive response or
>to push up their own capabilities in your eyes.

Obviously there is no way for me to know whether this is the case; however, I
have never seen anyone make that comment -- about anyone's code -- before or
since, so I cannot believe that it is a common way for new employees to suck up
to the old. I have not seen programmers suck up to one another at all -- it
seems like a pretty stupid thing to do.

>Sure, your code could in
>fact be the most readable code in existence, but a new employee pushing a
>positive response is not a good indicator - its simply human nature.

You sound like you have specific experience in this direction, so nothing I can
say would persuade you one way or the other. Our experiences differ.

----------

Getting back to the point, though, (objectively) clear code beats (redundant)
documentation. I think we can agree with that. We may disagree on the likelihood
of producing objectively clear code, but I think we can agree that documentation
ought to supplement code, and not just explain it. Code ought to be able to
explain itself. The code is the most accurate record of what the code does,
after all.

I simply believe that documentation should be one level of abstraction higher
than code; otherwise, the reader should read the code. Of course, if the team
needs documentation to fill a void, then it should build that documentation; but
I wouldn't build it until that need was felt. That's all I'm trying to say here.

Take care.


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603

>-----Original Message-----
>From: J. B. Rainsberger [mailto:jbrains@...]
>Sent: Thursday, July 03, 2003 2:24 PM
>To: junit@yahoogroups.com
>Subject: RE: [junit] Unit test java documentation
>
>
>>So said Chip Dunning on 2003-07-03 --------------------
>>> -----Original Message-----
>>> From: J. B. Rainsberger [mailto:jbrains@...]
>>> Sent: Thursday, July 03, 2003 11:29 AM
>>> To: junit@yahoogroups.com
>>> Subject: Re: [junit] Unit test java documentation
>>[snip]
>>>
>>> A top time-waster on software projects is writing useless
>>> documentation instead of clear code.
>>
>>I would agree that useless documentation is worse than clear code, but
>>then useless documentation is probably worse than messy code (as long as
>>the code at least works). However, I disagree with the statement - unless
>>you got something other than your own experience to back that statement up
>>with.
>
>You disagree with what part: that it's a time waster or that it's a "top time
waster"?

I disagree that it is "a top time waster" as you stated.

>As for "something other than your own experience to back that statement up
with", what on
>Earth is more important than one's experience?

The experience of a collective is more important than the myopic experience of
an individual. One person can only experience so much, thus we produce studies
and surveys and the like to draw upon the experience of many to understand
things that might be anomalies. Do you have a survey, study, or anything else
that I can take to my management so that we can improve our own process other
than "some guy on a list says that documentation is a top time waster"




Chip
-----
Programming: Its not just a job - its an indenture

>So said Chip Dunning on 2003-07-03 --------------------
>>-----Original Message-----
>>From: J. B. Rainsberger [mailto:jbrains@...]
>>Sent: Thursday, July 03, 2003 2:24 PM
>>To: junit@yahoogroups.com
>>Subject: RE: [junit] Unit test java documentation
>>
>>
>>>So said Chip Dunning on 2003-07-03 --------------------
>>>> -----Original Message-----
>>>> From: J. B. Rainsberger [mailto:jbrains@...]
>>>> Sent: Thursday, July 03, 2003 11:29 AM
>>>> To: junit@yahoogroups.com
>>>> Subject: Re: [junit] Unit test java documentation
>>>[snip]
>>>>
>>>> A top time-waster on software projects is writing useless
>>>> documentation instead of clear code.
>>>
>>>I would agree that useless documentation is worse than clear code, but
>>>then useless documentation is probably worse than messy code (as long as
>>>the code at least works). However, I disagree with the statement - unless
>>>you got something other than your own experience to back that statement
>up
>>>with.
>>
>>You disagree with what part: that it's a time waster or that it's a "top
>time waster"?
>
>I disagree that it is "a top time waster" as you stated.

I can sink my teeth into this. Are you willing to name, say, five bigger time
wasters, according to your experience? I'm not trying to grill you, but I am
interested in your perspective. I can learn from it.

>>As for "something other than your own experience to back that statement
>up with", what on
>>Earth is more important than one's experience?
>
>The experience of a collective is more important than the myopic
>experience of an individual.

No argument there. You can agree, though, that one's opinion is shaped most by
one's direct experience, in spite of what one may have read or heard.

>One person can only experience so much, thus
>we produce studies and surveys and the like to draw upon the experience of
>many to understand things that might be anomalies. Do you have a survey,
>study, or anything else that I can take to my management so that we can
>improve our own process other than "some guy on a list says that
>documentation is a top time waster"

No, I don't; but then, giving you ammunition to take to your management was not
my objective in writing the foregoing, so it's reasonable that my response
wouldn't factor that in, no?

Incidentally, isn't a study simply what one guy did? My point is: when does it
end? You can discredit or simply choose not to believe any study I might put
before you. At some point, you choose either to believe or you don't. This is
why I don't knock myself out looking for studies. I listen to stories (told
campfire-style around the bar at conferences) and I observe what happens around
me. I find it more authentic.

Take care.


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603

Hmmm, top 5 - given in no particular order.

1) Any meeting involving the majority of the team with someone more than two
steps removed from a current project.
2) Any meeting that reaches critical mass and can no longer reach a consensus -
or where at least one person or department is represented solely to boost their
billable hours
3) Impromptu meetings/discussion involving more than one question.
4) Wide open internet connections.
5) The latest management fad


I wasn't looking for ammo, I just saw the statement and was wondering if it was
more than "red is the best car color." When I asked I had assumed that if you
had a link to a roundtable discussion or conference/white paper on the subject
you would be willing to share.
	 Sure a study or white paper is just something that one guy did. But the minute
you put it into the public arena like that you are inviting public/peer review
and commentary. Thus, it reaches a far larger audience with a wider range of
experience than just the gang you tip back with on occasion.


Chip
-----
Programming: Its not just a job - its an indenture


-----Original Message-----
From: J. B. Rainsberger [mailto:jbrains@...]
Sent: Thursday, July 03, 2003 2:47 PM
To: junit@yahoogroups.com
Subject: RE: [junit] Unit test java documentation


>So said Chip Dunning on 2003-07-03 --------------------
>>-----Original Message-----
>>From: J. B. Rainsberger [mailto:jbrains@...]
>>Sent: Thursday, July 03, 2003 2:24 PM
>>To: junit@yahoogroups.com
>>Subject: RE: [junit] Unit test java documentation
>>
>>
>>>So said Chip Dunning on 2003-07-03 --------------------
>>>> -----Original Message-----
>>>> From: J. B. Rainsberger [mailto:jbrains@...]
>>>> Sent: Thursday, July 03, 2003 11:29 AM
>>>> To: junit@yahoogroups.com
>>>> Subject: Re: [junit] Unit test java documentation
>>>[snip]
>>>>
>>>> A top time-waster on software projects is writing useless
>>>> documentation instead of clear code.
>>>
>>>I would agree that useless documentation is worse than clear code, but
>>>then useless documentation is probably worse than messy code (as long as
>>>the code at least works). However, I disagree with the statement - unless
>>>you got something other than your own experience to back that statement
>up
>>>with.
>>
>>You disagree with what part: that it's a time waster or that it's a "top
>time waster"?
>
>I disagree that it is "a top time waster" as you stated.

I can sink my teeth into this. Are you willing to name, say, five bigger time
wasters, according to your experience? I'm not trying to grill you, but I am
interested in your perspective. I can learn from it.

>>As for "something other than your own experience to back that statement
>up with", what on
>>Earth is more important than one's experience?
>
>The experience of a collective is more important than the myopic
>experience of an individual.

No argument there. You can agree, though, that one's opinion is shaped most by
one's direct experience, in spite of what one may have read or heard.

>One person can only experience so much, thus
>we produce studies and surveys and the like to draw upon the experience of
>many to understand things that might be anomalies. Do you have a survey,
>study, or anything else that I can take to my management so that we can
>improve our own process other than "some guy on a list says that
>documentation is a top time waster"

No, I don't; but then, giving you ammunition to take to your management was not
my objective in writing the foregoing, so it's reasonable that my response
wouldn't factor that in, no?

Incidentally, isn't a study simply what one guy did? My point is: when does it
end? You can discredit or simply choose not to believe any study I might put
before you. At some point, you choose either to believe or you don't. This is
why I don't knock myself out looking for studies. I listen to stories (told
campfire-style around the bar at conferences) and I observe what happens around
me. I find it more authentic.

Take care.


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603



To unsubscribe from this group, send an email to:
junit-unsubscribe@yahoogroups.com


Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

> Do you have a survey, study, or
> anything else that I can take to my management so that we can improve our
own
> process other than "some guy on a list says that documentation is a top
> time waster"

In "Agile Software Development" Alistair Cockburn covers the topic of
redundant vs useful documentation at length. I don't remember if he actually
cites
some studies but his conclusions seem very well founded to me. The book is a
very enlightening read at any rate...

Johannes

--
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++

Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!

>> Do you have a survey, study, or
>> anything else that I can take to my management so that we can improve
>> our
> own
>> process other than "some guy on a list says that documentation is a
>> top time waster"

BTW, if I remember correctly, he didn't say *that*. He said
*unnecessary* documentation is a top time waster.

Regards, Ilja

--- In junit@yahoogroups.com, "Ilja Preuss" <preuss@d...> wrote:
> >> Do you have a survey, study, or
> >> anything else that I can take to my management so that we can improve
> >> our
> > own
> >> process other than "some guy on a list says that documentation is a
> >> top time waster"
>
> BTW, if I remember correctly, he didn't say *that*. He said
> *unnecessary* documentation is a top time waster.

Yes.  Argh.  <sigh>  this is one of the things that is so often
misunderstood and misinterpreted.  "XP/Agile means no documentation..
woohoo!"  Agile means barely sufficient documentation.  You do what is
needed... and just that.  That applies to pretty much everything.. not
just docs.   What does "needed" mean?  Several things... like the
customer valuing it enough to explicitly ask for it pay for it, like
providing a high level overview of the system for anyone needing to
find their way around, like providing enough detail for people that
will need to work on it later (what Alistair calls "setting up for the
next game"), like what's appropriate for the context.. an published
API needs more internal docs (think javadoc) than totally internal
functionallity.

Dave

Dear Members,

I would like to know if there is a way to print for example of the
name of the currently test when the test is running (change in some
way the output information). By default it prints at the begining of
each test case a dot: "." and if there is any fail or error the
letter "F" or "E" respectively.

.E...F.F.F..

So you don't have more information about the trace of the execution
of the test. I would like to get the following output more or less:
test1 ... OK
test2 ... F
test3 ... E
test4 ... OK
.
.
.

I guess there is a way to do that, but it is not so much documented.
Probably to extends the class ResultPrinter that implements the
TestListener interface, but I don't see how to get dynamically the
name of the test case (that is the name of the test method of the
testing class).

Thanks in advance,

David

I would like to know how to modify the output information in order to
inform in more detail the trace information about the test on the
execution process.

By the default the trace information is something like this:
....E..F...

there is no information about the test passed or not, I would like to
get something like this:
test1 ... OK
test2 ... E
test3 ... OK
test4 ... F
test5 ... OK
.
.
.
I know I have to extends the class ResultPrinter that implements the
interface TestListener, but I don't know how to get dynamically the
name of the testing method.

Thanks in advance,

David

>So said Chip Dunning on 2003-07-03 --------------------
>Hmmm, top 5 - given in no particular order.
>
>1) Any meeting involving the majority of the team with someone more than
>two steps removed from a current project.
>2) Any meeting that reaches critical mass and can no longer reach a
>consensus - or where at least one person or department is represented
>solely to boost their billable hours
>3) Impromptu meetings/discussion involving more than one question.
>4) Wide open internet connections.
>5) The latest management fad

Excellent list. I was trying to narrow scope to work within the team on the
project, though. I assume that the team effectively manages its members'
interaction with the rest of the organization or Customer. The last XP team I
was on did this well, so that's the context I live in. In that case, we can pick
#1, #2 and perhaps #5 off the list. (Maybe you consider XP to be the latest
management fad... :)

Also, on a team using Pair Programming, #4 becomes a positive.

That leaves #3, which is a big time-waster, indeed. The team needs to learn to
resolve issues quickly, including, "Let's just try it both ways and see what's
better."

It's amazing to me the number of items on your list that I don't worry about any
more.... when they come up, I simply walk out the front door. That level of
organizational dysfunction isn't worth my effort.

>I wasn't looking for ammo, I just saw the statement and was wondering if
>it was more than "red is the best car color."

Well, it certainly is, since that's an opinion, whereas my statement is based
both on personal experience and anecdotal evidence from people in the Agile
community. A formal study? No.

>When I asked I had assumed
>that if you had a link to a roundtable discussion or conference/white
>paper on the subject you would be willing to share.

Alistair Cockburn has done work on the time wasted in creating documentation for
its own sake. Andy Hunt and Dave Thomas' "Pragmatic Programmer" talks about it,
too, but this last reference is just more opinion/experience/anecdotes.

>      Sure a study or white paper is just something that one guy did. But
>the minute you put it into the public arena like that you are inviting
>public/peer review and commentary. Thus, it reaches a far larger audience
>with a wider range of experience than just the gang you tip back with on
>occasion.

Agreed.


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603

>So said Ilja Preuss on 2003-07-04 --------------------
>>> Do you have a survey, study, or
>>> anything else that I can take to my management so that we can improve
>>> our
>> own
>>> process other than "some guy on a list says that documentation is a
>>> top time waster"
>
>BTW, if I remember correctly, he didn't say *that*. He said
>*unnecessary* documentation is a top time waster.

Exactly. Sometimes we build documentation for its own sake. We should stop that.


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603

>So said David on 2003-07-04 --------------------
>Dear Members,
>
>I would like to know if there is a way to print for example of the
>name of the currently test when the test is running (change in some
>way the output information). By default it prints at the begining of
>each test case a dot: "." and if there is any fail or error the
>letter "F" or "E" respectively.
>
>..E...F.F.F..
>
>So you don't have more information about the trace of the execution
>of the test. I would like to get the following output more or less:
>test1 ... OK
>test2 ... F
>test3 ... E
>test4 ... OK
>..
>..
>..
>
>I guess there is a way to do that, but it is not so much documented.
>Probably to extends the class ResultPrinter that implements the
>TestListener interface, but I don't see how to get dynamically the
>name of the test case (that is the name of the test method of the
>testing class).

Each Test object has a name property. Call Test.getName().

Take care.


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603

Hi All,

I am new with JUnit. I have two test files and one test suite file,
unfortunately when I try to run the testrunner from any directory, I
always get a NoClassDefFoundError. Here is how my tree looks like:

C:
   Src_java:
     Dog.java
     Person.java
   test_java:
     DogTest.java
     PersonTest.java
     AllTest.java

all src classes are placed in Src_java directory and all test classes
are placed in test_java. Can somebody let me know what's wrong? Thanks

Charles

Hi,

I'd like to inform to Ant through command-line the name of the test
case I want to run.
If I don't send any parameter, a default Test Case should be run.
That is, what I want is:

ant -Dtestfile="TestCase1.java" ---> run TestCase1
ant -Dtestfile="" ---> run DefaultTestCase

I defined a default value in the build.xml file, like this:

<property name="testfile" value="DefaultTestCase.java"/>

This way, if I don't mention the property, i.e. if I call ant without
arguments (ant), it executes perfectly, running the DefaultTestCase.
But if I send a blank property (ant -Dtestfile=""), junit doesn't
know which test to run, because he looks for a test named "".

Is there any way of testing the value of the property, inside the
xml, and put a default in case of blank?

>So said Leonardo Abreu de Barros on 2003-07-04 --------------------
>Hi,
>
>I'd like to inform to Ant through command-line the name of the test
>case I want to run.
<snip />
>Is there any way of testing the value of the property, inside the
>xml, and put a default in case of blank?

No. You have to set the property or not, depending on what you want. This is a
JVM question, and nothing to do with Ant or JUnit. If you need more information,
read documentation about passing arguments to the JVM.

Take care.


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603

On Fri, 04 Jul 2003 19:30:28 -0000, "sutantoc74" <sutantoc74@...>
said:
> Hi All,
>
> I am new with JUnit. I have two test files and one test suite file,
> unfortunately when I try to run the testrunner from any directory, I
> always get a NoClassDefFoundError.
> [snip]
> Can somebody let me know what's wrong? Thanks

Charles,

This is a typical Java classpath issue.  What class name is in the stack
trace?  Make sure that class in on your classpath.  From a commandline
you can type one of the following to see what your classpath is set to...

     Unix:    echo $CLASSPATH
     Windows: echo %CLASSPATH%

--
=jason
[:question | ^One]

On Fri, 04 Jul 2003 16:57:48 -0400, "J. B. Rainsberger"
<jbrains@...> said:
> >So said Leonardo Abreu de Barros on 2003-07-04 --------------------
> >Hi,
> >
> >I'd like to inform to Ant through command-line the name of the test
> >case I want to run.
> <snip />
> >Is there any way of testing the value of the property, inside the
> >xml, and put a default in case of blank?
>
> No. You have to set the property or not, depending on what you want. This
> is a JVM question, and nothing to do with Ant or JUnit. If you need more
> information, read documentation about passing arguments to the JVM.

I think he meant "Is there any way of testing the value of the property
with Ant?"  I think you can.  Refer to Ant's documentation for the "if"
task.  However, I don't see why you would want to do this.  It simply
doesn't make sense to pass <empty string> and expect the default to still
occur.  Just don't set the empty string on the commandline.

--
=jason
[:question | ^One]

Here's one option, others are probably available using "if" and
"condition":

<target name="default-value" unless="testfile">
	 <property name="testfile" value="default-value"/>
</target>

On Friday, July 4, 2003, at 04:39 PM, Leonardo Abreu de Barros wrote:

> Hi,
>
> I'd like to inform to Ant through command-line the name of the test
> case I want to run.
> If I don't send any parameter, a default Test Case should be run.
> That is, what I want is:
>
> ant -Dtestfile="TestCase1.java" ---> run TestCase1
> ant -Dtestfile="" ---> run DefaultTestCase
>
> I defined a default value in the build.xml file, like this:
>
> <property name="testfile" value="DefaultTestCase.java"/>
>
> This way, if I don't mention the property, i.e. if I call ant without
> arguments (ant), it executes perfectly, running the DefaultTestCase.
> But if I send a blank property (ant -Dtestfile=""), junit doesn't
> know which test to run, because he looks for a test named "".
>
> Is there any way of testing the value of the property, inside the
> xml, and put a default in case of blank?
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Save on Coral Calcium. Get Better Health and
> Stronger Bones. Seen on TV
> http://www.challengerone.com/t/l.asp?cid-2805&lp=calcium2.asp
> http://us.click.yahoo.com/9gf46B/EfUGAA/ySSFAA/5cFolB/TM
> ---------------------------------------------------------------------
> ~->
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>