Hi there,
If one has a private variable and a public "setter" method in a class how would one go about testing this "setter"? Like to test if a particular object was actually set it would require a public "getter" which is exposing implementation.
Would it be best then to infer the validitity of the "setter" indirectly through testing another public business level method?
Regards,
James.
> Hi there,
> If one has a private variable and a public "setter"
> method in a class how would one go about testing this
> "setter"? Like to test if a particular object was
> actually set it would require a public "getter" which
> is exposing implementation.
> Would it be best then to infer the validitity of the
> "setter" indirectly through testing another public
> business level method?
> Regards,
> James.
You don't have to unit test every little method. Setters & getters are the perfect examples of methods I never test. You only need to test them when they contain meaningful business code, not just a plain assignment or return statement.
hth
Ok so I'm testing an example from "Junit in Action" by V. Massol. In the example there is an AccountService that has a transfer method to transfer funds between Accounts. To my mind this should be a private method as one would not want it abused. But it contains business logic I want to test. So how should one treat private methods in testing?
Should one test only public methods and in that way (maybe) indirectly test private ones thus ascertain their correctness?
James.
Your JUnit test is a client of the class that's being tested, so it should have no more access to private methods than any other client. That's one of the beauties of JUnit: it shifts your thinking and puts you in the shoes of your clients. You'll start designing that API to match their needs.
That does not mean that you should change that private method to public for the sake of testing. If it's not useful as a public method to clients, then leave it as private. Test the public ones.
%
excerpt from JUnit in Action, 3.3 (p.56) :
__
JUnit best practices: test anything that could possibly fail
Unit tests help ensure that your methods are keeping their API contracts with
other methods. If the contract is based solely on other components?keeping
their contracts, then there may not be any useful behavior for you to test. But
if the method changes the parameter抯 or field抯 value in any way, then you
are providing unique behavior that you should test. The method is no longer
a simple go-between梚t抯 a filtering or munging method with its own behavior
that future changes could conceivably break. If a method is changed so it
is not so simple anymore, then you should add a test when that change takes
place, but not before. As the JUnit FAQ puts it, 揟he general philosophy is this:
if it can抰 break on its own, it抯 too simple to break.?br>But what about things like JavaBean getters and setters? Well, that depends. If
you are coding them by hand in a text editor, then yes, you might want to test
them. It抯 surprisingly easy to miscode a setter in a way that the compiler
won抰 catch. But if you are using an IDE that watches for such things, then
your team might decide not to test simple JavaBean properties.
__
A good piece of advice to make your mind about all this ;-)
