Unit Testing : Accessor Methods : Mutable Object 2005-01-31 - By Marvin Toll
Back
Gerard,
Working for a fortune five company precludes waiting until AOP is adopted
as a corporate standard to get close to 100% automated unit test coverage
on an application.
I leveraged your suggestion regarding the notion that some folks perform
transformation on an attribute without any indication in the method name:
setMethod(int argumentA)
getMethod() returning a String
vs.
getMethodString()
A quickly coded (and a little bit tested) implementation is posted at:
http://gtcgroup.com/util/
_Marvin
On Sun, 30 Jan 2005 10:00:33 -0200, Gerard Toonstra <toonstra@(protected)>
wrote:
>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)
|
|
