Kalle, Interesting idea about unit tests as inner classes. At times I have been frustrated by lack of access to private fields ... I'll have to think about that one.
As for MyFaces, there appears to be some limited unit test stuff but not much. My guess is that the existing stuff will ultimately be rewritten anyways. So I think the door is wide open as far as how we want to approach unit testing in MyFaces. sean On 6/21/05, Korhonen, Kalle <[EMAIL PROTECTED]> wrote: > First, thanks Sean for doing the heavy lifting. Restructuring the whole > codebase is always more cumbersome than it should and you always end up > breaking some little pieces. But, it's needed and it's always better to > do it as soon as possible. Ignore people who'll ask "why do we need this > again?" :) > > > -----Original Message----- > > From: Sean Schofield [mailto:[EMAIL PROTECTED] > > Subject: SVN Reorg > > There are a few things that will have to be sorted out after > > the initial phase. One example is unit tests which are kind > > of scattered. > > One thing I've been promoting here is to implement unit tests as inner > classes. In case of restructuring and renaming, you wouldn't need to > worry about moving your unit tests; but they would always go with the > main classes. This somewhat controversial idea has several benefits: > - Your unit test class is always kept with the main class if you decide > to refactor it into a different package. > - You can name all your test classes the same way, for example as > UnitTests (so you get a bunch of classes called $UnitTests), which can > then easily be identified be removed from deployment builds. > - Inner classes can access all of the fields and methods of the parent > class, including private ones, so you don't need to compromise your code > encapsulation and information hiding design to instantiate and populate > the class you are testing. > - Since inner classes have the same scope as their parents, there's no > need to rewrite import clauses. > > Some say that then you'd be mixing your test code with business code, > but it's quite the opposite; when compiled, they are compiled as > separate classes and since inner classes can access all private members > of the parent class, you don't need to change your business code to make > it suitable for unit testing. It's a trivial exercise to delete all > *$UnitTests.class files from the output folder when you are ready to > deploy your classes. > > For MyFaces unit testing, just throwing out the idea for others to think > about. > > Kalle >
