Did a Little Work on CorePlot Test Cases
I'm trying to see how an Open Source plotting package for Cocoa on Mac OS X goes. It started a few weeks ago, and I think it's the right thing to do as it's the kind of thing I've wanted to have for the Mac for ages, and being a part of it almost guarantees that I'll understand it well enough to make use of it. So I'm trying my hand at this kind of thing.
Today I looked at the new testing framework someone put in. I can see the value of automated testing but I also see the problems. Today it was sloppy includes, poor test writing and missing test data. They were fixed easily enough, but it brings to mind the problems I see in automated testing in the first place: What do you really test?
I'm all for testing the public APIs of classes. That's what the class is supposed to do, and how it's supposed to do it. But private methods are another thing. I think that's asking for a ton of grief. If the method is useful enough, and important enough to test, then maybe it should be in the public API. If it's not that important, then testing the public API should exercise the private implementation details.
The guy that threw this test frame together didn't share my ideas. He's got compiler warnings testing private methods, and I just think that's not right - from several points of view. First, the testing, and then the compiler warnings. There just shouldn't be any. Period. It's so easy to remove these, and they are there for a reason - you're making a mistake. Maybe not a big one, but it's a mistake, and you need to stop right now and fix it.
Given that this is open source, it's not going to get fixed unless I fix it, but that's OK too. I don't mind being in that role for this project. It's interesting and the outcome is something I've wanted for a long time. We'll just have to roll with the punches and see where it goes.