• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

How-to unit test wrapper classes

 
Sheriff
Posts: 1367
18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm experimenting with an approach which pretty much looks like the Decorator pattern. I'm not yet sure this is an approach that will actually solve my problem in the best possible way, but I'm trying to prototype test first.

My first attempt at writing unit tests for this ended up involving far too many bits and pieces - not really unit tests at all, so I backed out, deleted everything and started over.

Now I find that I'm duplicating a lot of simple tests, since each of the little classes that act as wrappers for the base class(es) has the same behavior as the others to a large extent.

Should I test the common behavior in one place, and then restrict the unit test for each of the wrapper classes to the specific behavior that varies?

What about when I wrap the base object in four or five of the decorating objects? Are we still talking about unit tests, or have we crossed the line into integration testing?

I also need to test that I get the same result by wrapping the same object in the same decorating components in any order. Does this still fall under the umbrella 'unit test'? Not that I need to be semantically correct - I just want to get a better grasp of all of this (because honestly, I feel a lot more sane when developing test first!)
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Katrina Owen:
Now I find that I'm duplicating a lot of simple tests, since each of the little classes that act as wrappers for the base class(es) has the same behavior as the others to a large extent.

Should I test the common behavior in one place, and then restrict the unit test for each of the wrapper classes to the specific behavior that varies?


This sounds like a good idea. How do your wrappers look like? Do you instantiate a wrapper by passing the wrapped object in the constructor or what? Maybe you could write a generic "X is wrapper for Y" type of assertion, which uses Reflection to check that X has the appropriate constructor(s) and has methods that delegate to whatever instance of Y it is given?

Originally posted by Katrina Owen:
What about when I wrap the base object in four or five of the decorating objects? Are we still talking about unit tests, or have we crossed the line into integration testing?


Does it really matter how many decorator layers you have? From a given decorator's perspective, it doesn't care whether its base object is the real base object or a decorated base object, right?

Originally posted by Katrina Owen:
I also need to test that I get the same result by wrapping the same object in the same decorating components in any order. Does this still fall under the umbrella 'unit test'? Not that I need to be semantically correct - I just want to get a better grasp of all of this (because honestly, I feel a lot more sane when developing test first!)


This starts to be closer to the integration test domain, but I'd probably still call it a unit test if those different decorators execute fast, don't have side-effects, etc.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know whether I'd call them unit test - and I don't care. They sound like valuable tests to me, that's what counts.

I know two basic approaches to this kind of problem:

- testing the decorators in isolation by mocking the decorated object, and

- using the Abstract Test pattern to test the behavior that the same for all implementations: http://c2.com/cgi/wiki?AbstractTest

I'd recommend to try both approaches, to see which one serves you better.
 
Katrina Owen
Sheriff
Posts: 1367
18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My wrappers and wrapped objects all implement the same interface (or extend the same abstract class... I haven't made up my mind yet). The wrappers take an object of this type in the constructor.

Does it really matter how many decorator layers you have? From a given decorator's perspective, it doesn't care whether its base object is the real base object or a decorated base object, right?

No, it doesn't matter how many layers, but I'd like to make sure that my implementation doesn't care correctly (i.e. is doing it the way I think it is doing it).

Right now the tests execute very quickly (as do the decorators themselves). They only implement two methods: one is defined specifically for each decorator class (checking for custom criteria, as well as checking the result that gets returned from the wrapped object), the other just delegates an action to the object it is wrapping... only the base class actually acts on it.

Thanks for the suggestions on how to approach writing the tests. It makes a lot of sense!
 
Who among you feels worthy enough to be my best friend? Test 1 is to read this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth
https://coderanch.com/t/751654/free-earth-friendly-heat-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic