Tag: 'unit testing'
EasyMock Cause-Effect Exception Mapping
EasyMock is a great tool for separating external dependencies from unit tests. There is a learning curve to learning the mock method of testing, and unfortunately, EasyMock does not give very good prompts when you do something wrong. The exception messages are actually quite cryptic. This article is meant to be a crude mapping of exception output and the behavior that might have caused it. At least, this is a log of many of my experiences with EasyMock and how I usually get into the messes I do. It is quite possible that the same exception output could be had via different behavior. It's also important to note that I'm not trying to show how to create meaningful tests here (I don't even show full tests half the time), only help figure out how mysterious EasyMock exceptions were thrown. These experiences were documented on EasyMock 2.2 and 2.4.
Expose Fields via Java Reflection
For unit testing purposes, I often want to set field values in objects so that I can setup for the test conditions. One of most annoying things about testing is the urge to change code design for just the sake of testing -- especially if it's in a way that is considered less safe, like exposing elements or lessening accessibility. (This is not to say that trying to test code can reveal certain code smells and prompt refactoring). I, myself, have a number of setter methods with this comment prepended: "// for test only comments". Stinkers! Well, sometimes enough becomes enough. So, here's a way to set any field on an object w/o exposing it. This is done via reflection.
Java Reflection for methods with primitive params
First-class objects are the norm in the code that I usually write and edit, but every now and then I run across a method with a primitive parameter. I use EasyMock a lot in testing, and need to find these methods by reflection, this is how it's done...