All entries for Tuesday 11 October 2005

October 11, 2005

Hilarious!!!!

Writing about web page http://marinefishuk.co.uk.dns54.com/portal/forum/viewtopic.php?t=3605&highlight=&sid=2341b01dfe409f446f1b7d7479ddf7de

Even as a regular church goer, these were hilarious :)

These sentences actually appeared in church bulletins or were announced in church services

The fasting and prayer conference includes meals

The sermon this morning 'Jesus walks on water'. The sermon tonight 'Searching for Jesus'

Ladies, dont forget the rummage sale. It's a chance to get rid of all those things not worth keeping around the house. Dont forget to bring your husbands.

Dont let worry kill you off – let the church help.

For those of you who have children and dont know it, we have a nursery downstairs.

Irving Benson and Jessie Carter were married on October 24 in the church. So ends a friendship that began in thier schooldays.

At the evening service tonight, the sermon topic will be 'what is hell'? Come early and listen to our choir practice.

Scouts are saving aluminium cans, bottles and other items to be recycled. Proceeds will be used to cripple children.

Please place your donation in the envelope along with the deceased person you want remembered.

This evening at 7pm there will be a hymn singing in the park across from the church. Brink a blanket and come prepared to sin.

The pastor would appreciate if the ladies in the congregation would lend him thier electric girdles for the pancake breakfast next Sunday.

Low Self Esteen Support Group will meet Thursday at 7pm – Please use the back door.

The eight-graders will be presenting shakespears hamlet in the church basement friday at 7pm. The congregation is invited to attend this tragedy.

Weight watchers will meet at 7pm t the first presbytarian church. Please use large double door at side entrance.

The associate minister unveiled the churchs new tithing campaign slogan last sunday 'Ive upped my pledge – up yours!'


I'm such a technophobe :)

Writing about web page http://www.apple.com/itunes/

So I have only just installed itunes. I never really got what all the fuss was about until I suddenly noticed all everybody's playlist magically appear :)

I suspect it is simply doing a multicast call, but it;s well cool :)

Cannot believe I am so excited by this simple use of an age old technonlogy ;)


Absolute fantastic film

Title:
serenity
Rating:
4 out of 5 stars

Saw Serenity at the weekend, along with my non sci-fi loving wife. Even she enjoyed it :)

You don't need to have seen the original series to get this movie, although if you have, it makes the story much more poinant.

I think everyone should see this, it has the same laid back feel as the series, and each character's personality shines through. Even though it is obviously an action movie, it is most definately story and character driven.

Will definitely be getting this out on video when it comes out :)


Useful things to know with easymock :)

Useful things to know (this will keep being updated :)):

– if you forget to call EasyMock.replay() then you will get NPEs because your methods just return null

– if you create a strict mock (EasyMock.createStrictMock) then the order in which you define methods is important. Not even anal old me wants that much control :) Assume:

        ContentFetcher cfResponsible = EasyMock.createStrictMock(ContentFetcher.class);
        cfResponsible.isOwnerOfOwnContent();
        EasyMock.expectLastCall().andReturn(true);
        cfResponsible.setContent(content);
        EasyMock.replay(cfResponsible);
then if setContent is called before isOwnerOfOwnContent then you will get a stacktrace:
java.lang.AssertionError:  Unexpected method call 
 setContent(uk.....)
  isOwnerOfOwnContent(): expected 1, actual: 0

– EasyMock will not report uncalled methods until you call EasyMock.verify() at the end of your tests. It will report unexpected methods, but not the absence of expected methods.

Seems like quite a lot of overhead to use a mock object, an EasyMock.create***Mock(), an EasyMock.replay() and an EasyMock.verify().

JMock has the same limitation, but they provide a convenient test class which does the verify call for you. Oh well, let's perservere (how do you spell that!) :)


jmock versus easymock (a trivial example)

So I decided to have a look at easymock.

It looks very nice. Some of the main benefits include:

  • direct method calls, so refactoring works
  • less overhead required because you are manipulating your objects, not mocks

For example, there is an object call RequestScopeModelAccessor which stores/retrieves things under FlowScope within a web flow.

Using jmock, the get method can be tested:


    public void testGet() {
        String key = "key";
        Object obj = "object";

        // set up for writing
        Scope requestScope = new Scope(ScopeType.REQUEST);
        requestScope.setAttribute(key, obj);
        Mock context = mock(RequestContext.class);
        context.expects(atLeastOnce()).method("getRequestScope").will(returnValue(requestScope));

        RequestScopeModelAccessor accessor = new RequestScopeModelAccessor(key);
        assertEquals("get", obj, accessor.get((RequestContext) context.proxy()));
    }

whereas with easymock:


    public void testGet() {
        String key = "key";
        Object obj = "object";

        // set up for writing
        Scope requestScope = new Scope(ScopeType.REQUEST);
        requestScope.setAttribute(key, obj);

        RequestContext requestContext = createMock(RequestContext.class);
        requestContext.getRequestScope();
        expectLastCall().andReturn(requestScope);
        replay(requestContext);

        RequestScopeModelAccessor accessor = new RequestScopeModelAccessor(key);
        assertEquals("get", obj, accessor.get(requestContext));
    }

As you can see, the code is much easier to read, and the mock framework is much less intrusive with easymock.

This of course is a very simplistic example, but it has encouraged me to look a bit deeper :)

BTW: I am using prerelease 2.0 which will only work with jdk 5.


Unit testing using mock objects

So anybody who has worked with me knows that I am a huge fan of unit testing, and it is not unusual for the amount of unit test code to exceed the amount of code being tested.

Looking back, it appears that most of my unit tests are mainly transparent (white box) and I prefer mocks over stubs.

This was never really a conscious decision, but I am quite comfortable with it. The benefits of white box testing is that you know your code is doing exactly the right thing. For example, the code in Sitebuilder2 that generates the object graph for the site navigation is very expensive, and therefore it is critical that it does the right thing. For example, Page has a method "isPubliclyVisible", which is a simple boolean field. It is essential (for performance) that this is called before doing an expensive webgroups lookup, and this logic is built into the unit tests. Were I to do a black box approach, it could be argued that this logic is absolutely internal and should not be tested.

In order to define these restrictions, I use link to define mocks for any collaborators. Conceptually this is the right thing to do. Stubs would not give me the control I required. On the other hand, a lot more work is required to define your mock objects. JMock also falls down when it comes to refactoring because you describe all your methods using strings.

When would I use stubs? Well, to be honest, very rarely. When should I use stubs? I would recommend using stubs when you truly do not care about how your stub will be used.

One of the unfortunate asides of using jmock to explictly define the allowed method calls is that you can very easily end up having to modify the expectations on objects just because you change a seemingly independant line of code.

For example, assume I have a method on page called addPage(Page). Imagine I know have a unit test for the duplicate method:


  public void testSomething(){
    // some code….

    Mock mockPage = mock(Page.class);
    Page page = (Page) mockPage.proxy();

    HtmlPage sourcePage = new HtmlPageImpl();
    sourcePage.addPage(page);
  }

If I change the Page.addPage(Page) method to automatically set the site, i.e.:


  public void addPage(final Page page){
    getPages().add(page);
    page.setSite(getSite());
  }

then all of a sudden, anywhere I have mocked up a Page which is added to another page will fail. This is a horrible, but unavoidable consequence of using mock objects for which you are expliclty defining behaviour.

Had I used a stub to represent Page, no problem.

So I do firmly believe that mock objects have an absolutely invaluable place, but they do need to be used with care.

If you care about how your object will be used, use mocks, if you don't, use stubs. Are there mock object frameworks which provide a bit more flexibility; yes, easymock looks quite promising (link).

Will I learn, and start using stubs, probably not :)


October 2005

Mo Tu We Th Fr Sa Su
Sep |  Today  | Nov
               1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31                  

Search this blog

Tags

Galleries

Most recent comments

  • Interesting… While I'm not completely convinced in such microbenchmarks, I'm pretty sure that 1ms … by Alexander Snaps on this entry
  • Hello. I bought the book yesterday. I was trying to find the source code for chapter 11 and chapter … by Suleman on this entry
  • http://woosight.net/account/login?username=demo by live mashup demo on this entry
  • Thanks mate ….. This blog was really helpful. by Maaz Hurzuk on this entry
  • Ty. Not directly helpful for my problem, but pointed me in the right direction. You will also get th… by Mike E. on this entry

Blog archive

Loading…
Not signed in
Sign in

Powered by BlogBuilder
© MMXXI