Changing Lanes
By indomitablehef | February 19, 2008
DesignInDrive.com is being retired, but no fear, the madness continues at www.indomitablehef.com. I’m combining the posts from this blog, and continuing to post about software development, and whatever else is on my mind.
Topics: Uncategorized | No Comments »
Welcome!
By indomitablehef | January 1, 2008
If you’re new here, and you want to start reading the posts in order, here they are:
|
|
Topics: Uncategorized | 1 Comment »
Eric Evans on Domain Driven Design (again)
By indomitablehef | November 12, 2007
A full-length video presentation from Eric Evans on DDD: putting the model to work
I attended the DDD BOF (Birds-of-a-Feather) group at the QCon conference, hosted by Eric. Some of the things that resonated with me from that session:
1. Look for Pain Points
It should be a given that not all parts of a large, complex system will be well designed (he gave a presentation on that earlier in the week, too). So, don’t waste time doing a complete overhaul of an existing system in an attempt to take advantage of Domain Modeling and Domain Modeling. Instead, look for pain points, problems, things that are difficult, and things that annoy. There’s a good place to start refactoring towards a domain driven design.
2. Well placed Value objects
For clues on how to refactor towards DDD, look for places where you are passing strings around. A few well-placed value objects, instead of strings, can encapsulate domain concepts, and get you started in the right direction.
3. Bounded Contexts
Eric said several times that he wished that Chapter 14 of his domain driven design book had been chapter 2, because a lot of people never got to chapter 14, and it turns out that Bounded Contexts (the subject of chapter 14) are critical. Building anti-corruption layers between systems you have control over and systems you don’t have control over is a good way to maintain the purity of your domain model. These anti-corruption layers are a type of Bounded Context.
Update:
Another thought on those Bounded Contexts. A domain model is “a” model of a system, of a domain. It is rarely “the” model. And that’s ok. Multiple models may be useful for different purposes. In supply chain, the contract management model is different from the purchasing model. Much of the underlying system overlaps, but these different models are perfect for their different purposes. A bounded context (or bounded contexts), then, can be used to translate between the models, and preserve the usefulness of each.
Topics: Uncategorized | No Comments »
QCon San Francisco, 2007
By indomitablehef | November 12, 2007
I just returned from the QCon conference in San Francisco, which was completely AWESOME! So, hopefully I’ll be posting a lot more in the coming days/weeks about the things that I saw/heard/learned there. Stay Tuned.
Topics: Uncategorized | No Comments »
TDD Primer: Video
By indomitablehef | October 16, 2007
From ARCast.tv, a Test-Driven Development Primer with Peter Provost. (click “Watch”)
This 5 minute video does a fantastic job of introducing and reinforcing the idea of TDD. I plan to add it to my tool belt of evangelizing tools, and make all my friends watch it with me.
Topics: Uncategorized | No Comments »
How do you know when it’s working?
By indomitablehef | October 9, 2007
From a TDD Fanboy’s viewpoint, how you know your approach to TDD or just plain unit testing is working? - Jeremy Miller [codebetter]
Some good thoughts in the comments, too…
Topics: Uncategorized | No Comments »
TDD == TFD, and WWTDDD?
By indomitablehef | October 8, 2007
In recent discussions with colleagues about Test Driven Development, I was reminded of the importance of the “Driven” part of Test Driven Development. When I first heard about TDD, I naturally got excited about it. It sounds great. It’s obvious, really, once you see it. Obviously the way things should be.
But then reality sets in. Writing tests is an entirely new skill to learn, and not a particularly easy one, at that.
Think back on your first Object-Oriented development efforts. How “object oriented” were they, really? For many of us, our first attempts at OO ended up being very procedural solutions implemented in a rich object oriented programming language. In theory, we were gung-ho about OO. But we hadn’t yet transformed our way of thinking about problems into a framework that would take advantage of all the wonderful things that OO could offer.
How many of us eventually wandered off the other side of the trail? After realizing that we were stuffing square, procedural pegs into round, object oriented holes, we vowed never to make that mistake again. Every class had an interface, every object a factory, every entity an inheritance hierarchy, and we ended up with a polymorphinhericapsulatestracted mess.
TDD is much the same. It’s a new paradigm. A new world view. To really be effective at it, it must transform the way you think about software development (even in the database - but that’s a post for another day…specifically, after I’ve figured out how to do it better). I was at a conference recently (ITARC Atlanta - IASA Regional Architect’s Conference) where Scott Ambler said: “if you’re not writing tests, you’re not a professional”. Ouch. Seriously…that stings, because I know deep down that it’s true. Ouch.
My journey into TDD is far from done, and I haven’t yet earned my merit badge, at least in my own eyes. But I have learned a couple of things along the way.
1. TDD == TFD
The most important thing about TDD is that you must (absolutely must) write the test first. TDD is really TFD - Test First Development. It can be more than just “first”, but to do it well, it has to be done first. Why? If you don’t write the test first, you won’t write the test. My first two, maybe three attempts at TDD after I drank the Cool-Aid failed miserably because I did not grasp this concept. We all have time pressures (those of us that get paid to do this, anyway). When you are under pressure, and you’ve already written working software, the temptation to skip the tests (promising to come back to it later) is just too great. Under pressure, the mind looks for shortcuts, and finds them. Tests fall by the wayside, along with all your good intentions.
2. WWTDDD? (What Would Test Driven Developers Do?)
“Being TDD” is like coming to Jesus. There’s no way you can go back and atone for all the code you’ve written that doesn’t have a test. The best you can do is to start trying to do better today. If you have time to go back and write tests for something old, do it. Atone for past sins when the opportunity presents itself, but don’t wallow in guilt. But from now on, begin your day with testing. Begin every new task by writing a test. Get religion. Start by writing tests for anything new that you do, and write a test for any bug in existing code that you have to go back and fix.
I have these diagrams posted on either side of the door to my kyoobickle:
10 Ways to Improve Your Code - Neal Ford (www.nealford.com)
Introduction to Test Driven Design (TDD) - Scott Ambler (agiledata.org)
Topics: Uncategorized | No Comments »
Source Code for .Net Framework Libraries to be released later this year
By indomitablehef | October 5, 2007
Topics: Uncategorized | No Comments »
Acceptance Tests
By indomitablehef | October 5, 2007
This post is all “out of order”, since I should probably talk about User Stories first, but I feel guilty for not posting often enough, and when I have something to post, I reckon I’d better just throw it out there…so here goes.
Read up on User stories here: http://en.wikipedia.org/wiki/User_story
For every User Story, we should have one or more acceptance tests. I use index cards, (4×6, but I wish I had stuck with 3×5). I write the user story, title, number, and effort estimate (in story points) on the front of the card. I write the acceptance tests on the back of the cards. Like everything else along the way towards agile development, writing user stories and acceptance tests is a growing process. Our first pass at acceptance tests for our stories was woefully inadequate, but it got us used to the idea and got us thinking in the right direction - believing in the principle.
Now, we’re working on getting better at it -writing “good” acceptance tests. Remember that user stories are written by users. So are acceptance tests. Still, everyone will need coaching, and sometimes hand-holding. Take it slow, be a salesman, not a tyrant. (something I have to remind myself of)
Acceptance Tests
Think of them as a script that you will eventually use to evaluate whether a story is complete. Imagine a scenario where you write the story on the front of the card and hand it to the developer. When the developer is done, he returns the card to you. You then flip it over and proceed through the acceptance tests, and if all the conditions you specified are satisfied, then the story is done.
Acceptance tests are “black box”: that is, they focus on expected results or observable behavior. Avoid design discussions whenever possible.
An example:
Story: Add Patient Health Risk
The Clinician selects a drug from the patient’s list of drugs, and enters a Health Risk related to that drug. He selects Risk category/subcategory from drop-down lists (see cat/sub-cat list), and selects severity (severe, critical, major, moderate, minor) and status (identified, opened, closed-resolved, closed-unresolved, pending) , also from drop-down lists. He can enter notes for the HR and Sub-Category specific details (see list of detail fields for Health Risk sub-categories).
Acceptance Tests
1. A Clinician can view a patient, select a medication, and choose to add a Health Risk specific to that medication.
2. A Clinician can enter category/subcategory/status/severity/notes/sub-cat-details for the Health Risk and save it.
3. A Clinician can view a list of Health Risks for a patient and see, at a glance: Drug/Cat/SubCat/Severity/IdentifiedDate, Status. List should be able to “group by” the available columns and filter by status/severity combinations, as well as Identified date ranges.
4. The system automatically records status change dates and user info whenever the status of the Health Risk changes. Status history info is available on the Health Risk detail view.
5. The system will not allow the Clinician to add multiple Health Risks for the same drug with the same category/subcategory.
Things to notice:
- #3, #4, and #5 are not specified in the original story. These are the kind of undiscovered requirements we hope to uncover while writing acceptance tests.
- #4 is packed full of undiscovered requirements:
- It mentions a “Health Risk Detail View” not discussed in the story – a requirement tucked into a prepositional phrase at the end of an acceptance test.
- “whenever the status of a Health Risk changes” – when does the status change? At the very least, this probably means that the user can edit the Health Risk, but this hasn’t been mentioned yet, either in the story or the acceptance tests. It could mean more: are we expecting the status to change automatically based on some event? Better find out now.
Some questions to kick start the brain when writing acceptance tests:
- I will know this story is complete when:
- I will be satisfied that this is done when I can:
- For this to be complete, the solution must be…
- For this to be complete, the solution must have the following qualities:
- When complete, the solution must meet the following conditions:
- When complete, the solution must conform to the following standards:
Topics: Uncategorized | No Comments »
Domain Driven Design
By indomitablehef | September 24, 2007
An interview with Eric Evans on Domain Driven Design. [infoQ]
Topics: Uncategorized | No Comments »
Chris Hefley (the indomitableHef) is a software developer/architect from Nashville, TN.