can't mock Calendar java class

[Hamlet D'Arcy]

Anybody have any insight about trying to mock java.util.Calendar?

groovy-user post is here: http://permalink.gmane.org/gmane.comp.lang.groovy.user/25704

[Scott Vlaminck]

Hamlet,

I think the problem is that you are returning the mock itself, rather
than a mocked instance (upon which the extra demand has been set). The
tricky part is that most times inside the 'use' you would instantiate
the class that you are mocking, but with an abstract class that
doesn't work so well. So you need a concrete subclass to also mock
out. You could create a concrete subclass of Calendar and implement
the handful of abstract methods to mock out ... or just use one of the
concrete subclasses, like GregorianCalendar.

It seems like unnecessary overhead, but I guess that's maybe part of
the problem mocking an abstract class that also wants to manage the
construction of the concrete class it returns. A working example is
below.

Scott

/////////////////////////////
def calendar

def mock = new groovy.mock.interceptor.StubFor(Calendar)
def mockGCal = new groovy.mock.interceptor.StubFor(GregorianCalendar)

def mockTimeZone = new
SimpleTimeZone(3600000,'Europe/Paris',Calendar.MARCH,-1,Calendar.SUNDAY,3600000,SimpleTimeZone.UTC_TIME,Calendar.OCTOBER,-1,Calendar.SUNDAY,3600000,SimpleTimeZone.UTC_TIME,3600000)

mock.demand.getInstance() { calendar }

mockGCal.demand.getTimeZone() {mockTimeZone}

mockGCal.use {
calendar = new GregorianCalendar()
mock.use {
def cal = Calendar.getInstance()
def timezone = cal.getTimeZone()
println timezone
}
}
/////////////////////////////

On 10/17/07, Hamlet D'Arcy <Haml...@gmail.com> wrote:
>
> Anybody have any insight about trying to mock java.util.Calendar?
>
> groovy-user post is here: http://permalink.gmane.org/gmane.comp.lang.groovy.user/25704
>
>
> >
>

--
-------------------------------------------------
Scott Vlaminck // sc...@refactr.com
Refactr LLC // http://refactr.com
mobile // 612-386-9382
-------------------------------------------------

[Hamlet D'Arcy]

The post helped... but I never did get what I want accomplished.

I was trying to write unit tests for the groovy.time package and that
means mocking out all the calendar stuff so that timezones and
daylight savings time don't affect test runs. I thought I had it all
working, and I tested it in several time zones. However, in my last
test it ended up failing in some weird south american time zone. I
gave up eventually.

I've been really happy with Groovy overall, but the unit test
capabilities aren't everything I hoped they would be. I absolutely
love the partial interface / partial class approach you can take with
closures (passing a closure/map instead of a real depended upon
component). But I was under the wrongful impression that static method
calls could be mocked out in Groovy. This seems true if it is a groovy
based class making the static method call, but if the static method
call has been compiled into my java class then I can't mock it out the
way I thought I could. (this is totally due to my lack of
understanding about groovy and not any sort of language deficiency).
My real life example is that my compiled Java class that I want to
unit test calls the database using a static method on a depended upon
component. It looks like I'm going to just extract out the static
calls into a new class that isn't static and write the unit tests as
usual in JUnit.

I'd love to start checking groovy tests into my work's test tree, but
at this point I don't see partial interfaces/classes as a big enough
advantage to be able to sell the powers that be on the idea. I'm going
to keep plodding on in groovy though. I spent so much time in groovy
the other weekend that going back to Java on Monday morning was a bit
rough. :)

Thanks for the reply!

> On 10/17/07, Hamlet D'Arcy <Hamlet...@gmail.com> wrote:
>
>
>
> > Anybody have any insight about trying to mock java.util.Calendar?
>
> > groovy-user post is here:http://permalink.gmane.org/gmane.comp.lang.groovy.user/25704
>
> --
> -------------------------------------------------
> Scott Vlaminck // sc...@refactr.com

> Refactr LLC //http://refactr.com
> mobile // 612-386-9382
> -------------------------------------------------