Interface based programming: +1 Cleanup, clarity is good...have at it. I also noticed amongst the drivers (or collections?), several implementation details could be inherited/shared. I believe one of your unit test points to a case, the collection with slash test.
As an aside: Mock Objects may be something that you would be interested in using for junit testing, with controlled responses from objects with interactions. -Kevin Ross -----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Kevin O'Neill Sent: Thursday, August 07, 2003 12:46 AM To: [EMAIL PROTECTED] Subject: Core interfaces I believe there are some problems with the index manager and it's ability to handle namespaces so I thought I'd write some unit tests as none exist in this area. Well it turns out to be very problematic for two main reasons. The internal classes are all concrete and most of the methods are final. Looking at IndexManager it's initialised with a collection. The collection is used in 5 places and only a few methods are called (getSymbols, getFiler, flushSymbolTable, and as an argument to a couple of constructors). My first idea was to create a reflection proxy that responded in known ways for these methods and spat the dummy for anything I didn't know was needed. This is something I do all the time for tests. Opps, can't do that, Collection isn't an interface :(. Okay then I'll create a cheesy subclass and override the methods to respond as I need. Nope, most of the methods are final. I don't want to create an entire database for testing and I want to be able to control the responses from methods like getSymbols but it looks as though I'm going to have to make alot of infrastructure to run some simple tests. I'd like to create interfaces for the significant core components, database, collection, whatever else people think is appropriate. This will make creating unit tests alot easier. Thoughts? -k.
