@psilokan - yes, pixelated -- good eye! been using it for a while now...
@MCII - The JMockit code looks a lot different than what most people with a strong mocking background are used to seeing, but I think the way it works is more in tune with Java programming idioms. The static block is how you work with the expectations API. It's grown on me a bit, though.
You see the double chicken-lips in other forms. I personally prefer the static block to defining some type of anonymous inner class and having to implement interface methods.
I also don't mind the way this looks/works over all. Typically I don't want to define Expectations or "overridden behavior" for a period longer than the test method, anyway. The mocks can get reused, but what you're expecting on the mock is specific to a particular test method. I'm actually more comfortable never assigning them to a variable!
,
Comments
psilokan replied ago:
Heh, the infamous pixeled theme
MCII replied ago:
Argh! Static block in anonymous class. The example is really ugly.
cwash replied ago:
@psilokan - yes, pixelated -- good eye! been using it for a while now...
@MCII - The JMockit code looks a lot different than what most people with a strong mocking background are used to seeing, but I think the way it works is more in tune with Java programming idioms. The static block is how you work with the expectations API. It's grown on me a bit, though.
You see the double chicken-lips in other forms. I personally prefer the static block to defining some type of anonymous inner class and having to implement interface methods.
I also don't mind the way this looks/works over all. Typically I don't want to define Expectations or "overridden behavior" for a period longer than the test method, anyway. The mocks can get reused, but what you're expecting on the mock is specific to a particular test method. I'm actually more comfortable never assigning them to a variable!
,
Voters For This Link (10)
Voters Against This Link (0)