tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <br...@pingtoo.com>
Subject Re: unit test debugging under Netbeans
Date Fri, 30 Dec 2011 02:45:04 GMT
On 28/12/11 22:27, Konstantin Kolinko wrote:

Thanks very much for your time and valuable thoughts, Konstantin.

> 2011/12/28 Brian Burch<brian@pingtoo.com>:
<snip/>
>> However, I was a bit surprised to discover I couldn't simply "wire up"
>> netbeans to compile, run and debug any of the tomcat unit tests!
>>
>> netbeans provides three standard ide actions for what it calls "free-form
>> ant projects", such as tomcat. These ide actions expect the ant build.xml
>> for the project to have three corresponding targets that can be "connected"
>> to these actions.
>
> Are you saying that NetBeans cannot run an arbitrary user-chosen
> target of build.xml, but needs them to have specific names in English?

I was saying that, but your question prompted me to check more carefully 
and now I see I was wrong.

Netbeans automatically creates a build.xml and project.xml for most 
kinds of new projects using "standard" target names and wiring them to 
standard ide actions.

However, when "introducing" an existing project to netbeans as what it 
calls a "free-form ant project", all the (rather confusing and 
out-of-date) documentation assumes that you will adhere to the existing 
naming conventions. I can now see that an ide action in project.xml can 
be associated with any valid build target.

In other words, I do not need to create new targets simply to achieve a 
redirect to an existing target that already does the desired job.

> It cannot run an arbitrary target under debugger?

As far as I understand, that question makes sense with eclipse, but not 
with netbeans.

Because netbeans projects are (always and only?) manipulated through 
their ant build.xml (either created by wizards, or pre-defined in 
free-form projects), all projects need a target that will start the jvm 
in debugging mode and then call the nbjpdastart task to connect to the 
debugger socket. If not, then you can't debug.

When I want to debug tomcat itself, I just run "catalina jpda start" 
(thus running it outside netbeans) and tell netbeans to start a debugger 
session to connect to the target jvm. However, when I want to debug a 
unit test under the netbeans ide, I believe I need a suitable ant 
target. However, I'll give your question more thought...

> Note, that you can specify a single test name in build.properties.

Yes, I noticed that was the case. My netbeans project.xml already 
assigns the ${test.entry} property to the selected fully-qualified 
classname before calling ant to run my two new single test targets.

>> I would be happy to update the wiki to describe this process, but I don't
>> want to write a load of stuff about modifying the checked-out build.xml when
>> it would be MUCH easier to commit my changes to the trunk first. My changes
>> are intended to be completely safe when ant runs outside netbeans.
>>
>> I'll just describe the changes for now, to see what kind of reaction I get:
>>
>> 1. existing runtests macro: netbeans looks for a brief non-file junit
>> formatter so that it can hoover junit results when running a single unit
>> test class and then prettily present them within the workbench gui. I have
>> added such a formatter, but made it conditional upon running under netbeans
>> and wired it to the run-single ide action.
>
> Formatter is configurable since 7.0.24.

Silly me! A ${test.formatter} property is defined immediately after 
${test.name}! However, the runtests macro assumes I want usefile="true", 
but that prevents netbeans from intercepting the results.

I will think about whether I really want both formatters active on the 
same netbeans test run (as in my current version). If not, I need to 
work out how to inject a value without the user having to change it in 
build.properties, where it would affect non-netbeans test runs.

>> 2. new target compile-selected-files-in-test: the name of this target is
>> defined by netbeans convention. I have a cut-n-paste mod of the existing
>> test-compile target that accepts a list of classes to compile, because I
>> couldn't see a trivial change to your existing target.
>
> You must compile all files and pack them into jars etc. as needed. It
> is not possible to compile a single file.

I was talking about compiling a selection-list of unit test classes. I 
remember that eclipse compiles classes on-the-fly. Netbeans /appears/ to 
do the same thing, but it actually only compiles the class in the editor 
window (to show compilation errors), not into the project build 
directory. When you run an individual test class under netbeans, it MUST 
have been previously compiled by the ant build.xml into the correct 
output directory. This process seems to be working fine for me already 
because netbeans/ant submits the individual class file to run under the 
jvm/junit.

[note to self: the run-single and debug-single targets are dependent on 
the test-compile target, thus triggering a compilation of the selected 
single unit test file (if necessary), as well any other classes that 
might have changed. Without it the user would be confused by testing an 
old version of the class, while viewing the last saved version in the 
workbench.]

Do unit test classes really get jar'd and run from the jar? (I couldn't 
see this when quickly looking at the build.xml.)

>> 3. new target debug-selected-file-in-test: this is a cut-n-paste mod of the
>> runtests macro. I need to run junit under the jvm debugger and attach the
>> netbeans nbjpdastart ant task to let the gui control the test.
>
> The same as above.

I felt it would not be appropriate to add a significant amount of 
netbeans-specific conditional logic to the runtests macro to support 
debugging of a single test class. It seems much "cleaner" to have a 
separate ide-specific target, even though it needs to duplicate a lot of 
the existing runtests logic.

>> So... can I submit a patch for these three changes to build.xml? I am sure
>> this will make some of you nervous, but it seems the cleanest approach to
>> me.
>>
>> How (specifically) should it be submitted - bugzilla?
>>
>
> Yes.

OK. I need to think about these issues and improve my changes first, so 
you won't see anything specific for a couple of weeks.

> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message