Unit Testing : Accessor Methods : Mutable Object 2005-01-30 - By Gerard Toonstra
Back
Hi Marvin,
Generally, unit tests ignore setters and getters. I think it could also
be dangerous to "test" them, because the idea of having them is that you
can change other attributes, do validation or allow the input to be different,
so that you can change the internal representation of that data according
to other specific needs. For instance, to get an IP number, I probably would
record this as a long internally, but when a "get" is used, I might return
it as
a string of octals. What you "get" in the test is then no longer the same
as what was "set" ( internal other attributes changing, and so forth ). A
generic testUtil cannot interpret this difference without additional
programming.
You could use aspect driven programming and write code once.
According to my interpretation of your needs, you want to confirm that when
a setter is invoked, the internal attribute is changed and get returns the
same.
From within the aspect, you could weave in code for every public set* method.
Get the parameters from the setter using the aspect, confirm that after the
setter
returns, the private attribute of the instance was set to the same value.
Optionally,
invoke a get on the same object and compare the return value to the object
that you
have from the parameters or the internal attribute even. Using this method,
only the
setters actually invoked during the test run will be tested.
After the run, you might confirm the aspect actually worked for all setters
and that it
actually executed. So, within the aspect record the joinpoint executed
somewhere
( Set, Map or whatever ). Then a final test collects all the getters and
setters for
every class using standard reflection, compares what that got with the ones
actually
invoked and raises any problems.
The same methodology could be used to do simple test coverage. Use a hashmap
to record method invocations using a different aspect. Then using standard
reflection,
get all methods available. The difference between the two results in a
percentage which
is a measure for your test coverage. You don't get nice HTML reports and
line coverage
results, but you get some good idea what is left untested.
Certainly, you only want to weave in these aspects during test runs, not in
debug or
release builds :)
Cheers,
Gerard
At 18:59 29/1/2005, you wrote:
>Although this forum does not normally focus on unit testing core patterns -
> the topic is at least tangentially related.
>
>I'm curious if anyone has "run into" a unit test utility method for
>verifying accessor methods on a mutable object. A unit test might look
>something like:
>
> /**
> * Verify accessor method(s) of mutable business object (BO).
> */
> public void testMutableBusinessObject() {
>
> ExampleBO exampleBO = new ExampleBO();
>
> assertTrue(TestUtil.verifyAccessorMethodsForMutable(exampleBO));
> }
>
>... and TestUtil.verifyAccessorMethodsForMutable() would use reflection
>to "discover" all matching getters/setters and verify that setters return
>the "same" attribute object (or primitive value) as was passed to the
>corresponding setter. The class would instantiate attribute objects (or
>assign primitive values) for testing.
>
>Of course, it would also be nice to have an immutable version that
>verified attribute objects were "equal" but not the "same".
>
>Or perhaps, someone has an alternative strategy for achieving unit test
>coverage on accessor methods???
>
>_Marvin
>
>====================================================================
>Companion Site: http://www.corej2eepatterns.com
>J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
>List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
>Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
>
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.300 / Virus Database: 265.7.4 - Release Date: 25/1/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.4 - Release Date: 25/1/2005
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
