Tag Archive
admin agile ant bea classpath hell coding standards common sense design doh eclipse economics ejb Hibernate humour ide IE intellij ioc Java javaworld junit language design learning management maven meh nytimes opinion patterns personal Politics refactoring Ruby struts suncorp tdd testing testng unit testing usa web app web design weblogic weblogic workshop wotif
RSpec, JRuby and Story Testing Java Code
I’ve long been interested in decent ways of expressing tests in a human-readable format. Not just any humans, but BAs and business reps in particular – the kind of people who will not be interested in slugging through piles of language syntax. I tried Fit sometime ago, and was impressed, but when I came back [...]
Testing EJBs without a container
One of the more annoying aspects of testing EJBs has always been the fact you need to bundle them up in a JAR (and often an EAR) and deploy them to a server to thoroughly test them. This process drags out the development of unit tests, and makes life generally painful.
As of EJB 3, however, [...]
Interfaces with EJB3
Starting last October, we went through a process of upgrading the main application at Wotif to be running under Java EE 5 (not just Java SE 5). The biggest part of this was upgrading from EJB 2 to EJB 3.
One of the things I noticed was that EJB3 gives you a lot of choices for [...]
JBR’s Postulate 1
From the JUnit mailing list, courtesy of J.B "JUnit Recipies" Rainsberger
JBR’s postulate 1. For every testable design that requires exposing elements “just for testing”, there exists an equivalent testable design that does not require exposing elements “just for testing”.
It’s a bird, it’s a plane… it’s a super call?
Martin Fowler wrote about the Call Super smell. This occurs when you are allowed to override a method in a parent class, but you must (as opposed to can) call the parent implementation in your method.
Text files, test data, and the Jakarta Commons BeanUtils
Earlier, I wrote about testing only one thing at a time. A little one-liner I tossed out in that was using text files to load object graphs in your test cases. I thought I’d elaborate on that a bit more.
Testing pattern: don’t test too much at once
This has been said before, I know, but it’s worth re-iterating: a test should test one thing, and one thing only.
First, some scope definition. Using Kent Beck’s terminology, I’m talking about developer tests, not acceptance tests. Also, by one thing, I mean that there should be only one thing that breaks the test (which is [...]
Testing patterns: don’t assert without cause
One thing that I see a lot of with JUnit tests are “cascade failures”. That is, one change causes lots of tests to break. This is often (not always) associated with tests that assert things they shouldn’t.
Learn in the quiet times
I had a comment lodged on an older article recently. The poster was complaining about the poor quality of the JWebFit sub-project of JWebUnit In particular, he was complaining about how it meant their project wasn’t delivered on time. There’s an anti-pattern here.
Differences cause problems
This is obvious, but differences between environments cause problems. You can expect bugs to cluster around them.