[iframe width=’480′ height=’360′ src=’http://www.vyclone.com/embedded/5074a98b52fcef1a1f000a29′ frameborder=’0′ scrolling=’no’ allowFullScreen]
You are agile…
Just a collection of links to other people’s GWT testing techniques:
Testing GWT’s async services: http://www.jmock.org/gwt.html
Mocking widgets in the view: http://www.assertinteresting.com/2009/05/unit-testing-gwt/
Simon Stewart’s example app: http://code.google.com/p/tdd-gwt-gae/
I was ambling through some blogs that Google Reader suggested to me, and came across an article by Joe Ocampo on ‘How healthy is your code‘. It reminded me of something I heard mentioned on a project recently. It went something along the lines of ‘You are not properly stuck into a project until you have introduced some technical debt’.
It’s no surprise that the project is now struggling to maintain the rate of delivery that it started off with. Check out ‘Listening to test smells‘, a good way of showing there may be trouble ahead.
Another interesting outcome of a discussion on the subject can be found at Exploration Through Example, Brian Marick’s blog.
There’s a few things that annoy me, the widgets in GWT don’t easily allow you set an id on them, which means when it comes to testing, Selenium etc. has difficulty. So I’ve started a project called Geez that aims to add a bit more of a fluent way of building GWT apps… find it here:
Please note, they are very young, and I haven’t spent lots of time on them yet – so don’t whinge too much! That said, I’m more than happy for people to contribute ideas, code, tea – anything, just ping me.
I had an interesting discussion with someone I work with over pairing sessions today, and I was very impressed with his conclusion. This was, albeit subtle – ‘there are some people that you pair with, where the best of both of you come out in the code, and there are others, where the worst of both of you come out in the code’.
Too true… there are definite boundaries when pairing, and allowing your pair to explore the code within those boundaries, before reeling them in, is a good thing. However it is definitely down to the pair as to where those boundaries lie. Sometimes there may be no scope for allowing debt / poor quality code in, and in others, it may be acceptable as the pair trusts itself to go back and fix the poor quality code before (or immediately after) checking in.