While investigating the internal structure of JUnit 4.10 and Unitils I came across an Eclipse plug-in to aid the practice of continuous testing. I had wished for such a tool but did not know something existed yet. The plug-in Infinitest executes unit tests in a developers workspace after each change. If you are of the opinion that unit tests should run as often as possible this is probably as comfortable as it can get.
Continuous testing is a science-based practice that researchers at MIT studied. They concluded that this practice in general yields better (less defects in the same time) results, even if developers are not very experienced in test-driven development.
I was really excited about finding out that there was a plug-in working with current Eclipse releases called Infinitest. I tried and it worked right away. Usage is super-simple. It was open-sourced some time ago.
Here is the link to the InfiniTest project: http://infinitest.github.com/
I use it for a couple of days now and was addicted right from the start. The plug-in developers implemented quite smart decisions on when to run which test. Specific tests can be excluded using configuration files which will be in version control.
Note that running each test after each save means that having a seperate, well-designed and testable domain model increases the fun resulting in using this plug-in :-).
Recently I decided to re-read some of my favorite books. Domain-Driven Design. Tackling Complexity in the Heart of Software is one of the books that are so excellent that I am still really excited about.
I would like to bring DDD into the minds (and hearts) of every developer, architect and manager. While doing research I got the idea to grab memorable cites from a discussion of the book (Silicon Valley Pattern Group’s Discussion on DDD, with author Eric Evans attending) and provide a condensed version. I compiled the statements that seemed most important to me as an appetizer for everyone to read during a coffee break.
Note that this article is mostly no original work but consists of citations from the notes of the Silicon Valley Pattern Group’s discussion. Also note that this short overview does not replace reading the book itself.
- Capturing information at a higher, summary level.
- Q: How do you avoid analysis paralysis?
A: Don’t separate analysis phase from design. Code up a prototype that you can demonstrate and play with to help discuss what was needed. If you get a wrong answer, then it helps the domain experts catch an issue, discuss it with you, clarify it.
- There’s a difference between a model and a language, but they are tightly bound, and it helps to listen very closely to how the domain experts would naturally like to express their concepts.
- Refactoring is about about preventing the progress from slowing down.
- Deep Modeling is about enabling acceleration of progress
Communication and the Use of Language
- Do I emphasize speech enough? I feel that the speech center of our brain is one of the best modeling tools.
- In speech, we could go through a hundred variations of a model in an hour. You really need that. Tweaking the little pieces, changing the nature of a relationship, dropping an object, it makes things a little better. When I’m really working with a domain expert, I need to move quickly and fluidly.
- Speaking exposes awkward terms in a way that writing doesn’t.
- Even reading out loud is enough like speaking that it picks up these things.
- I feel it [discussion about coding style] expresses something about this style of coding — that naming instance variables within a method is tying it to the model, the ubiquitous language reaching down into the finest grain. That’s why it’s important, I think. In other modeling books, we’d be talking about high abstractions, and here we’re talking about the details of practice that make things work.
How to introduce Domain-Driven Design into your company
If Domain-Driven Design is not a major hype topic in your company I have some hints on how to introduce DDD softly:
- When setting up a project make sure every stakeholder agrees and understands the intention of Domain-Driven Design. This includes, of course, the developers and architects.
- Explain to your client and the domain experts how digging deep into the domain will pay off in the end. Try to find examples in the past where obligatory use of a Ubiquitous Language and a good domain model would have eased further develoment. Prepare the client that there will be a lot of discussion going on.
- Remember domain experts to really block their schedule when you are discussing the domain model. Telephone calls, ad-hoc meetings and other disturbances make it hard to concentrate.
- Explain to your client that Domain-Driven Design complements agile development methods, object-orientation, clean-coding and every hype topic that may currently be around. DDD aims to provide methods and guidelines to eliminate misconceptions early and continuously.
- Align the terms the developers use to those of the domain experts. This takes at least some initial days of intensive work and needs to be repeated now and then.
- Everyone involved in the design meetings must be aware that hundreds or thousands of wrong ideas about the domain may come up. Eliminating wrong ideas fast in a straightforward way is why it is important to really speak about the domain loud and in person and not communicate via e-mail or groupware.
Have fun – and tell me about it!