I'm working through the simple refactoring example in Refactoring by Martin Fowler and using the method he describes for JUnittesting. Problem is, within the JUnit framework, how do you test private methods?? The refactoring example Customer class has two private methods getTotalAmount() and getFrequentRenterPoints() that return a result and can't be called from a TestSuite. Presumably these are critical values to a customer. What do you use when that happens? A simple main method in the class? Or is the problem just that the refactoring example is simplified and in a real case scenario a 'statement' object would exist and TotalAmount and FrequentRenterPoints would be fields inside Customer with public accessors and would be updated when a statement is called?? Insights would be greatly appreciated
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I'm a good ways into my first project with JUnit, so I'll offer what I can. I don't normally test private methods. The most important tests, long term, are the public methods, and protected methods of public classes that will be extended outside the package. I like it best when I write these looking the javadoc comments. Writing the tests often shows me see that I left important information out of the javadoc, and sometimes leads to tweaking the specification. But some days the tests seem to get ahead of the javadoc, which feels wrong. I'm also testing a lot of package-visible stuff, especially since one of the packages has lots of internal classes hidden behind just a few public interfaces. I often think of the package-visible stuff as though it were public for this purpose. There has been a time or two I made something package-visible just for test purposes. When I do that, I put a warning in the javadoc that this methods is for use of so-and-so only, and sometimes put in a bit of extra precondition checking code to verify that it is not being called in a way that would obviously cause a problem (e.g., blowing the stack, not yet initialized, etc.). I've not done refactoring with JUnit other what occurs as I write the initial code, but I imagine that before starting a major refactoring, you would want to have especially good automated test of your externally visible methods, so you can detect when you break something while refacting. I would think that when refactoring, tests against private methods would be especially troublesome, because these test are likely to break or become useless as you refactor.
Joined: Aug 30, 2000
Thanks guys. Guess I'll use JUnit for testing the exported interface and use main() in the class to test the private stuff. Mainly I was curious to find out if I'd misunderstood the example 'cause Fowler mentioned running tests at various points in the refactoring and I couldn't figure our how he was testing the private methods if he did all his testing with JUnit.
Jane, I attended a users group meeting a while back where Refactoring was discussed and the presenter went through the example too. He said he'd written Martin Fowler and asked for the unit tests used for the example. I think he got them but he had some trouble with JUnit during the demo so we really didn't get to see that part. Anyway, since Martin has had some past involvement with the Ranch, maybe he'll send you those tests. Junilu