Hi Kohsuke,
Kohsuke Kawaguchi wrote:
> I'm all for improving project files for any IDE. This is relatively
> easy to do with, say, Eclipse, because we know whatever changes we
> make to .classpath and .project won't affect anything else.
No problem with that. I just believe we have good reasons to start with
Netbeans IDE in the first place.
> 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.
> 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 our goal is to improve the quality of the code, and enable
> developers to take a bigger risk in making changes, knowing that any
> regressions would be caught quickly.
100% agree with your position.
> 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.
> 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.
> 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?
> Yep. I'm all for that. In fact I believe tests in the new harness will
> be co-located with the source.
Cool. I actually plea for unit tests in particular, but co-locating
other tests with the code would be even better.
> Again, the reason why old tests are in a separate place is not a
> technical one, but rather legal and historical ones.
Yes I understand that, but I have got an impression that those are not
unit tests, right?
WBR,
Marek
--
Marek Potociar
Web Technologies & Standards
Sun Microsystems Czech