One of the odder practices of “conventional” software development that I’ve ever come across is the post-release test cycle. It’s something that has baffled me ever since I first saw it; you go through the normal development cycle, including testing, and then you deploy to production – and then you test it again. Sometimes with test cases that weren’t done during development. Why?
Continue reading “Post-Release Testing – what’s that about, anyway?”
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 and revisited it recently, it looked a lot like the community had kind of faded away. Accordingly, I looked around at what else was available, and stumbled across RSpec Now, I want to test Java code, and RSpec is for Ruby (as the R kind of hints), but I was able to get this going under JRuby fairly easily. I couldn’t find any examples of other people doing that, so I thought I’d write it up.
Continue reading “RSpec, JRuby and Story Testing Java Code”
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, it’s no longer necessary. instead, it is fairly trivial to mock out the container entirely (and safely!)
Continue reading “Testing EJBs without a container”
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 how to implement and configure EJBs and their associated interfaces. There’s a lot of “standards” on how to do it, many of them conflicting, but very little explanation of why. This is the set of standards I came up with (and was largely successful in getting implemented), and why I chose them.
Continue reading “Interfaces with EJB3”
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”.
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.
Continue reading “It’s a bird, it’s a plane… it’s a super call?”
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.
Continue reading “Text files, test data, and the Jakarta Commons BeanUtils”
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 very different from saying any failure should only break one test…). In addition, the one thing that breaks should provide diagnostic information – a test failure shouldn’t leave you scratching your head to determine the immediate cause
Continue reading “Testing pattern: don’t test too much at once”
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.
Continue reading “Testing patterns: don’t assert without cause”
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.
Continue reading “Learn in the quiet times”
Software is too expensive to build cheaply.... 