Marek Potociar wrote:
>> I thought today's NB project files in JAX-WS works --- you can edit
>> source files with code completion, right?
>
> Actually, no. You can't do that for APT related classes - CompileTool
> for instance.
Perhaps a quick fix for that is to rip off APT-related classes from
tools.jar and copy it into a jar somewhere in the workspace, just so
that IDE can refer to it. I used to do that in the JAXB RI.
>> I'd rather prefer to investigate ways to improve the NB project files
>> in JAX-WS without modifying build.xml.
> build.xml is a base config file for NB project setup. (I do not mind
> having it this way, but it may be a good opportunity for another RFE, if
> you wish.) Currently there is no way to avoid extending this file with
> some NB specific extension points. I repeat - it is more like an
> extension, not rewriting all existing tasks.
I think this is the source of concern for some of us.
>> It doesn't really matter what names you give to tests, and we just try
>> to get to better coverage within the constraints of resources.
> I do not necessarily agree with you on that. Actualy it does matter. You
> have to have a common terms and understanding of them to discuss a
> topic. Otherwise you may end up with a discussion in which everybody
> talks about something different. There is a commonly accepted test type
> classification, in which each type of test serves a different purpose.
> We do not have to invent what's been already inveted just for the
> inventing sake.
What I was saying is that the goal of the tests is as I outlined, and I
don't really care if we primarily use unit tests to meet this goal or
use other kinds of tests to reach this goal.
I'm not saying I disagree with your definition of "unit test".
>> I think the current and proposed JAX-WS test set up satisfies this
>> need. Tests are run fairly quickly enough after a commit is made, so
>> we do enjoy most of the benefits of what you describe.
> There are several caveats though:
> 1. you have to commit to find out that something went wrong.
> 2. with 'general' tests not focused on low level testing you are not
> able to discover all problems. You just test most common high level
> scenarios that came to your mind when you designed your tests. But that
> does not necessarily ensure that you also fully test the intended API
> behavior.
> 3. writing real unit tests (I really want to emphasize the difference
> between a test and a unit test) helps you also understand better the
> requirements placed on your API.
> 4. unit tests allow others a good starting point when trying to discover
> what your API does and what is its intended use. You cannot cover that
> much detail by any document nor by any higher-level test.
I appreciate you took time to educate us.
>> It's also worth pointing out that in JAX-WS, "API" is fairly small,
>> and not that interesting. Most of the interesting stuff happens with
>> dynamically generated/composed pieces, so testing the JAX-WS RI needs
>> somewhat different approach than testing, say, java.io.File.
> All you are saying may be perfectly true. But at the same time it cannot
> be considered as an excuse for not having unit tests, right?
I think no one is arguing that writing unit tests is a bad idea.
It's a simple economics. For our problem domain, we found that the kind
of tests we have today takes less of our time, lasts longer, and works
better. We only have limited time and people on the team, so it's only
natural that we pick up the best bang for buck. I should also point out
that this kind of test mode is fairly common in many places. Take a look
at how javac test suite is written, or how groovy unit tests are written.
If you call that an "excuse", then I really don't know what else I can say.
Again, this is not to say that we shouldn't be writing per-class unit
tests. I'm sure there are fairly isolated pieces here and there that can
be easily tested in isolation. I do have a few of those in the JAXB RI,
for example.
It's just that the majority of the code is really hard to test in
isolation, and exercising some codepath requires a fairly extensive set
up. Thus the kind of unit tests you are describing doesn't really make
much sense for many parts of the JAX-WS RI. Consider, for example,
testing SEIInvoker in isolation. You'd have to have a complete SEIModel
and WSDLModel just for a starter. You'd be better off using the code in
JAX-WS to build them, and you quickly end up what we do today, namely to
actually drive the whole service object instantiation.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com