Interface Defunc
Ok, so I am designing to interface... Sounds like I on a track until I get to the implementation... I have a private instance member that I write public getter/setter methods. Now how on earth I would go about using them in my interface reference?
interface intfs{
// method1, method2, method3
}
class intfsimplimplements intfs{
private String str;
// getter/setter, method1, method2, method3
}
Now I wouldn't be able to use my getter/setter methods:
intfs ifs =new intfsimpl();
ifs.setStr("uh oh");
Any suggestion?
Don't use getters/setters at all. Set the values once, in the constructor.
Hah, I do set the value in the construction. I augmented getter/setter to the implementation because I wanted to run a test case and came to the realization that I wouldn't be able to test the instance member -- I didn't have access to it. Seems like the more you add, the more you end up in the first square.
So removal of those getter/setter would leave me with only one solution for a test case: reflection. Am I right?
If you remove the getters and setters from the API, then you don't need to test them.
But if you really, really want your getters/setters, then don't code to the interface in your test. I don't see the problem.
Hmm... you are right, I am testing the implementation no the interface. But either way, the getters and setters would be expose as non-essential part of the contract and only used in the test case.
If I remove them then I wouldn't be able to test the instance member, you see what I am saying. If I include them as public methods, then if the user of the interface call them, it craps out.
When it comes to testing, is reflection only way to test private methods and member variables?
I don't have nearly as much doing automated testing as I'd like.
But in the past when I've had tricky testing issues, I'd build a test directly into the class, rather than having a separate test class (or I'd do both, with the external test class invoking the internal test method).
This isn't a great solution, because (theoretically) a user of the API might start treating the test method as part of the normal API. For example, as a worst-case scenario, maybe your "testInternalState" method returns the string "PASSED: internal widget value 5", then some idiot using your API might read that and try to parse out the 5. Ideally any internal test methods wouldn't make this possible.
You might also be able to have a package-private test method, and another class in the package invoking it. That way, the method wouldn't be visible outside the package (i.e., it wouldn't be in the API).
Or, depending on what you're doing, maybe you can have a "test mode" constructor for the class, and it will log trace output while it runs. This is good for debugging although not so much for automated testing.
Generally though I'd ask whether you really need to test something like that. It's not fulfilling the API if it's not defined in any interface it implements, so do you really need to test it? Maybe your energy is better spent creating more tests for the API methods.
I am new to this and from what I have been reading, a lot of people emphasize on testing every aspect of your code or designing it in such manner that it can be easily tested on its own. In addition, it has to be tested in its 'context' along with other components blah blah...
I can easily test the public API and was trying to extend the testing to the private parts. I was reading somewhere that even the methods should encapsulate a single responsibility so it can be tested in isolation. I don't really think that would be possible unless elimination of task delegation be the instinct your class possess.
*sigh*
The private methods encapsulate the implementation, which might change any time. As long as the implementation continues to work via the public API there is no need to test them, and writing tests for private APIs whose signatures and indeed presence might change at any time is really a waste of time.
If the publicly contracted API methods work, and they call the private methods, the private methods work. If there are private methods that aren't exercised by the public API, delete them.
ejpa at 2007-7-29 13:32:12 >
