05 June 2008
Public training courses?
We've had a couple of inquiries about whether we will be running our training course publicly. We hadn't planned to, but perhaps we should. We propose to run a two-day course priced at £1100 if booked less than 4 weeks ahead of the teach date, with a discount to £800 if booked earlier (plus UK VAT). The most obvious location is London (UK).
If you think you might be interested (no commitment implied), please drop us an email at public.course@mockobjects.com with this information:
Name: London is acceptable: Preferred other location: Preferred month for teach date: Possible number of attendees: Coding experience (years): TDD experience (years): Contact email: Contact phone:
We'll see if we can work something out
In case you're feeling nervous, whatever details we receive will be used only by us just to coordinate a course. We won't hassle you or pass them on to anyone else.
Labels: jmock, junit4, news, training
30 May 2008
Talk at London Geek Night.
Nat and I gave a talk at the most recent London Geek Night. It was an introduction to our approach to Test-Driven Development, incidentally making the point that some of the state- vs. interaction-based TDD wars are a bit specious; it's a matter of picking the right tool for the job. We had a good crowd and some useful questions. Afterwards, there was a Code Dojo in which Nat took part while I got stuck at the back talking to people. Thanks again to our hosts for an interesting evening.
We've uploaded the slides with notes. The format's a little odd because we used the toolchain we use for our courses, but the material's all there.
There are couple of other relevant links. Nils Haugen has a nice talk he did on Improving Test Maintainability, which is about making sure the tests make sense. Our interest is more in the stage after that, which is about listening to what the tests are telling you about the design of your code.
23 May 2008
Learn from the source!
Nat, Romilly Cocking, and I are now open for business for training. We have a course on Test-Driven Development that reflects nearly a decade of experience writing tests first (that's 30 years in parallel). We also have significant experience in training, Romilly has a couple of decades on his own, and Nat and I have taught commercially and at two of the top CS departments in the country.
The course teaches the practice of Test-Driven Development, based on a solid understanding of Object-Oriented design, and with a strong emphasis on making tests expressive and maintainable. We also make a point of exploring how unit tests can be used to drive the design of the code, not just protect it.
The content is modular, so we can adjust it to match the needs of the participants. The full-length course is three busy days, and we've taught versions that are a half-day and whole-day long.
We teach the course using jUnit4, Hamcrest, and (of course) jMock2. Talk to us if you want something different.
For more information, contact us at: training@mockobjects.com
Here's what some attendees liked about the course:
“The practical exposure to a better way of testing”
“Practical lab work, real-world concrete examples, Expert lecturers!”
“Chance to make mistakes and learn. Exposure to new technology.”
“A very good whole picture view of TDD and mocks”
“Interaction and explanation of course materials particularly through the exercises.”
Labels: jmock, junit4, news, training
08 March 2008
Another round in the testability debate
This time a posting from Mark Seemann has raised a slew of comments.
One of them is a note from Colin Jack about the annoyance of producing interface/implementation pairs all the time. My first response is that that sounds to me a bit like a problem with style. Maybe it's just wordplay, but usually I don't extract interfaces from classes, I implement interfaces that I've already discovered in some previous test.
My second response is to wonder how much this is a tools issue. I don't believe there's anything in the .Net world that yet matches the responsiveness of the usual Java IDE's. It makes a difference as to what's plausible. I remember the huge shift in perception when first VisualAge for Java and then JetBrains' Idea came out. In retrospect, I always spent more on time on rework than many people I worked with 1 but it sure took a lot more time in emacs (and I was pretty good at it), even if I was working in a better language.
1) which is not to say who was right, I'm just wired that way...
Labels: design, ide, testability
12 February 2008
New Tutorial at QCon
Labels: news
20 January 2008
Just when you thought it was safe to go back in the water...
Rising to the bait again (to keep the fishy metaphor going), there's yet another discussion of how the ability to hack the runtime changes the world. At one level that's true, but not in this case.
Dependency Injection is not a recent invention that a cabal of TDDers forced on the world, and it's absolutely not something that we came up with just so we could crowbar in our Mock Objects.
The relevant design guideline, named the Law of Demeter ("Strong Suggestion" isn't very catchy) was first described by Karl Lieberherr in 1987! The Mock Object pattern came from people applying their substantial O-O experience to TDD in Java, trying to figure out how best to avoid exposing implementation details in unit tests. One of the critical lessons from Demeter is that objects should have explicit dependencies. It helps to keep them focussed on their responsibilities and, as a result, easier to maintain—and a good way to make dependencies explicit is to pass them in.
Unfortunately, since then the world seems to have filled up with DI frameworks which cloud what should be a coding style discussion. This is not about having to configure every last corner of your application in XML, this is about how objects, or small clusters of them, get to talk to each other.
Roy asks, "[...] do you need DI all over the place, or just in specific places where you know dependencies could be a problem?" Well no—if you have enough foresight to know where those places are. I'm struggling at the moment to test against a framework where everything is helpfully packaged up nice and tight so I can't create an instance of one of its core objects. It's actually well written, but the authors just weren't good enough at prophecy to figure out my particular need. That's why I don't rely just on my intuition, I use the needs of my unit tests to help me figure out where the seams should be. To counter the FUD argument, I have absolutely no problem with saying that I don't want tools that do magic because I need guidance with my code.
As Roy (very politely) concludes, there isn't a high enough proportion of really good code in the world (some of it mine) that we should be in hurry to cut back on techniques such as DI. Just because something has been around for a while doesn't mean it's been superseded, especially in as conventional an environment as .Net.
Labels: design, testability
13 January 2008
Avoid mega unit tests
We've just had a posting to the jMock user list that included the following:
I was involved in a project recently where JMock was used quite heavily. Looking back, here's what I found:
- The unit tests where at times unreadable (no idea what they were doing).
- Some tests classes would reach 500 lines in addition to inheriting an abstract class which also would have up to 500 lines.
- Refactoring would lead to massive changes in test code.
I've seen this failure mode on another project I've been helping with, so I think there might be a common pattern.
I don't think any unit test code should get that large, except for unusual circumstances. Unit tests are supposed to focus on at most a few classes and shouldn't need a large amount of set up. What I saw on the other project was enormous amounts of preparation and positioning to get the objects into a state where the expected feature could be exercised. Of course it's hard to understand the point of a test when there's just so much code. If you see this pattern, then I'd suggest that the code (or at least the test code) needs breaking up a bit. On the other hand, integration and acceptance tests that happen to be written using a unit test framework might well be larger.
One thing I need to explore is whether the naive use of interaction-testing is particularly susceptible to this failing, or whether it happens all the time and we're the only ones who get complained to. I am, however, convinced that the emphasis on mainly using Mocks to substitute external systems (some of which I perpetrated myself in the early days) is a deeply bad idea which pushes teams towards the sort of problem described here.
Labels: design, listening to the tests, testability
© The authors
