Re: comments to JUnit spec

Some comments from me too.

I think focussing too much attention on a 1-1 correspondence between 
source methods and test methods may be a mistake. Sometimes it happens 
that way, but usually it doesn't (I am guessing). Similarly, trying to 
have the IDE "help" you make a test for more than one source at a time 
is just a waste of time.

No mention here of running individual test methods. This may be possible 
with Ant 1.7 - follow the RFE in the Ant bug database and think about 
how we could use it.

"Action like running or debug[g]ing tests will work only with the main 
project (current project)." - huh? That would be a regression from NB 
4.1 if so. I don't understand why this sentence is here, please remove it.

"...sometimes could happen, that a source root miss its test root. In 
this case IDE will ask, before a test class will be created, how this 
situation should be solved. NetBeans will display a dialog, where the 
user can choose an existing folder or set the name for the newly created 
test root." - would require an API change. Be careful.

s/JavaDoc/Javadoc/g

I don't think the UI should offer to create test suite classes by 
default, since in typical situations they are not necessary. They should 
be considered a relatively advanced feature of JUnit and either excluded 
from the UI or relegated to a secondary part of the UI.

There looks to be too many checkboxes in the Create Tests dialog. It 
reminds me of NB 3.x too much - overcomplicated and not that useful. 
Pick something reasonable to do and don't ask too many questions. E.g. 
create method bodies that just fail("TODO write me").

Don't offer to make setUp and tearDown methods. Usually you don't really 
know if you will need one until you are writing the test, anyway. (And 
tearDown is used much less than setUp in most domains.) You can add a 
1-line comment to the source telling user to press Ctrl-I to add these 
as needed. Think about something more useful, like a refactoring 
available only in test cases that would let you select a block of 
variable initializations in a test method and move the variables to be 
fields and the init code to setUp().

Get rid of the option "Generate main() method". The IDE (and generated 
Ant scripts) let you run JUnit tests directly without one, so why 
support it?

Re. r/o text fields - they should be setEditable(false), *not* 
setEnabled(false) which results in an A11Y problem. setEnabled(false) 
should be used only for controls which are currently unused (e.g. 
because some introductory checkbox is off).

JUnit result window - should IMHO use Progress API to display progress 
of running tests, using the new hooks available in Ant 1.7 where available.

Generally, I think most of the existing JUnit GUI is of limited value 
and we should be looking for things that really improve productivity and 
add value to the text editor. For example, what do I need to do to make 
a mock version of some class in my sources to simplify testing - will 
the IDE help me? Not now. Could it? Probably yes.

-J.

-- 
[email protected]   x22801   netbeans.org   ant.apache.org
if I had known it was harmless I would have killed it myself