TDD: Learning NUnit

By indomitablehef | September 23, 2007

While making the switch back to NUnit and learning to use version 2.4, I found some excellent resources I’d like to pass on…

Topics: Uncategorized | No Comments »

Meet the new boss, same as the old boss

By indomitablehef | September 23, 2007

So, let’s skip the “sorry I haven’t posted in awhile” stuff and just get on with it, shall we?

After five months of trying to get used to the Unit Testing framework in Visual Studio.Net, I’ve decided to go back to NUnit. This is my first experience with version 2.4.x, with the new constraint-based assert model. One of the benefits of unit tests is their self-documenting capacity for documenting your application’s code. Examine the Unit tests, and it should be clear how the application is supposed to work. With the new constraint-based model in NUnit 2.4.x, you can now write your assert statements in a way that reads almost like an English sentence. Here’s a simple example:

Assert.That( myString, Is.EqualTo("Hello") );

Sweet, huh? So, yeah, it’s nice that Microsoft is including Unit Testing with Visual Studio, as well as other tools like MSBuild, etc., but I’m back to believing that they just aren’t ready yet.

Coming up: More agile-enabling practices, like Automated Builds with NAnt and Continuous Integration with CruiseControl.net.

Topics: Uncategorized | No Comments »

The Post Whiteboard Domain Model

By indomitablehef | May 10, 2007

You may remember from our domain model discussion that a domain model has three important components:

  1. a visual representation of the business concepts and their relationships
  2. a shared language between developers/modelers and the business experts (domain experts)
  3. a software representation of the domain model

When you start, you generally start building these components in order. First, you draw some boxes and lines on the whiteboard, tape up some CRC cards, or whatever. While working through it, you keep track of the conversation between developers and stakeholders, and you allow the ubiquitous language to begin to form. Once you reach the point where you have “just enough” to know where to start writing code, you start building the really important part of the model, the code itself. You choose a section of the model to start with, and begin your first development iteration. During this iteration, there may still be moments where you decide to completely re-work the model, throw out most of the code you’ve written so far, and start again .

As soon as your first iteration of writing code is complete, the character of your domain model design approach begins to change.

Up to now, your “core” domain model has been the few objects you think you know the most about, or that you believe to be the most important. You’ve hammered down the basic relationships between core objects (Contract, Vendor, Manager, Shipment, Cargo, etc.), and you’ve been tinkering around the edges to see where things fit.

Now, you’ve chosen a section of the model (preferably the aforementioned core), and built it. At this point it begins to become more expensive to just throw away all the code you’ve written and start again. Through Refactoring and Test Driven Development, we can make the changes we need to make to our design when needed, but an important milestone has been reached. Now we actually have a Domain model - with all three of the necessary components.

For future design discussions, then, your model design must reflect what you’ve already built. Changes to the design that affect what has already been built should not scare us, since we have TDD and Refactoring tools for that very purpose, but all our design efforts from now on must take into account the actual model we’ve built in code. Remember that we are not bothering to model everything, just the important core domain and subdomains. These domain concepts and the diagrams and shared language that pertain to them must be tied to the core of the code itself.

In practice, this may mean that most of the modeling you did before writing your first line of code is placed on the shelf as a resource we can go back to later for ideas. You begin your domain model again, modeling the core objects that you actually built. As you proceed with future iterations and increments and future design discussions, you may pull in classes and relationships from your original modeling efforts into your new “official” model. But from now on, all your modeling activities are centered around either refactoring or adding to the model you’ve built in code.

This is also when the Ubiquitous Language you’ve developed begins to become very useful. Once you have a few working classes written in code, it’s time to revisit that language, and read through it to make sure the statements it makes are true for the code you have written. Just like the model diagrams, you may find yourself trimming the fat out of the language you’ve captured so far, so that what is left is the part that reflects the reality of the model (the code). As you add to the model in the future, adding to the code, you add to the diagrams and you add to the shared language.

Topics: Uncategorized | No Comments »

Design Darwinism

By indomitablehef | May 3, 2007

One of the unfortunate things that can happen when an organization begins striving toward a more purposeful design and development process occurs when a rigid design structure, framework, or set of “standards” is introduced. Some frameworks are good and useful, of course. Tried and true models of data access, network protocol, or even UI models/frameworks can speed the development process along. The trouble comes when trying to define a design model to be used at an application or domain level. It’s usually fine to say that we intend to deliver a thin-client/web application up front. It may not be a good idea, however, to specify that we will use Data Mappers throughout, and that all services must be Singletons and the UI must be a pure MVC implementation using Front Controllers. These attempts to specify a large scale structure up front can become an evolutionary handicap for an application or a design. Application-specific decisions on large-scale architecture or domain model structure can have the same effect. Too often, a framework is defined early in the domain model/application design. As situations emerge that don’t fit the framework, developers will “make it work” within the agreed upon/dictated framework, instead of questioning and refactoring the framework itself. As often as not, this is the result of an ITA run amok. (ITA = Ivory Tower Architect). Avoid these large-scale decisions early in the design and implementation effort, and let the details of the architecture evolve instead.

In Domain Driven Design. Eric Evans calls this “Evolving Order”:

Design free-for-alls produce systems no one can make sense of as a whole, and they are very difficult to maintain. But architectures can straitjacket a project with up-front design assumptions and take too much power away from the developers/designers of particular parts of the application. Soon, developers will dumb down the application to fit the structure, or they will subvert it and have no structure at all, bringing back the problems of uncoordinated development.
The problem is not the existence of guiding rules, but rather the rigidity and source of those rules. If the rules governing the design really fit the circumstances, they will not get in the way, but actually push development in a helpful direction, as well as provide consistency.
Therefore: Let this conceptual large scale structure evolve with the application, possibly changing to a completely different type of structure along the way. Don’t overconstrain the detailed design and model decisions that must be made with detailed knowledge.

Let the model evolve as your understanding grows. This includes the large-scale structure of the model, not just the details inside the core. Societies and organisms that cannot evolve eventually collapse or become extinct. Let your design use fins and gills for awhile, but don’t be afraid to give it legs and lungs when it’s time to take it onto the beach.

In addition to the “ITA run-amok” problem, developers who are learning the practice of software architecture can sometimes take the guidelines that are handed down, (or written about in books/articles) too literally on their own. Our limited understanding of design patterns and models can sometimes influence us into the attitude that we should be working harder to make the model/pattern work. I know - it happened to me. It helps to remember that the goal is not to make a model, pattern, or framework “work”. We’re building software, remember? Make the software work. When the model doesn’t work, change it. Don’t build your scaffolding out of brick and mortar.

Topics: Uncategorized | No Comments »

Agile Project Management

By indomitablehef | May 2, 2007

I’m working on some more thoughts on managing projects on an agile team. I’ve been doing some reading on the subject, and trying to make it work in my organization. Until I have my thoughts ready to post, I’ll share a couple of the things I’ve been reading/listening to:

Managing the Work in an Agile Project - Dan Rawsthorne, PhD, CSM

Agile/Lean Documentation: Strategies for Agile Software Development - Scott Ambler
and check out the Featured Webcast (I can’t link directly to it, so find it on the page), at IASA - Scott Ambler on the basis and implementation of agile architecture.

Topics: Uncategorized | No Comments »

Home Sweet IndomitableHome

By indomitablehef | May 2, 2007

I’ve neglected this blog for the past couple of weeks, while I’ve been busy buying and moving into this little house in Franklin, TN.

myhouse.jpg
backofmyhouse.jpg

But I’m back!

Topics: Uncategorized | No Comments »

Agile Implications

By indomitablehef | April 15, 2007

In the last few posts, we’ve been talking about Agile Development and the practices that enable it: Iterative and Incremental Development, Refactoring, Active Stakeholder Participation, and Test-Driven Development. Of course, I’m simplifying the concepts implied by “Agile”, in an attempt to distill what I see as the core foundational elements. These are things we need to begin to put into practice in order to take advantage of this approach to software development.

Now, let’s consider some of the implications of this approach, with respect to “the way we’ve always done it.”

Getting out from under the waterfall and moving to an Iterative and Incremental approach doesn’t mean the absolute end of the “phases” we’re used to. The activities of Analysis, Design, Construction, Testing, and Deployment still have to happen, after all, if we’re ever going to build anything useful and get it into the hands of the people who need to use it. What it does mean is that these activities are no longer corralled into distinct phases, but instead are woven throughout our development cycle. You can look at it as if these activities now fit into our Iterations and Increments. For example, in a given “Increment” (i.e., a set of features we’ve deliver all together at one time), it might go like this:

Before you go copying that down and writing it into your project plans, remember that it’s just an example. The point here is that these activities now flow fluidly. Part of the reason for “increments” then, is to take a moment at the end of each increment to evaluate the approach you took in the previous one. Evaluate how you planned and executed your iterations. How well did you do “Test Driven Development”? What kind of participation were you able to get from the stakeholders? It’s a time to “tweak” your approach - capitalize on your strengths, correct mistakes, improve on your weaknesses, and to stop doing things that don’t add value.

Of course, almost all projects will start with some analysis up front. The key is to keep it lean, and remember that “you will never know enough.” In upcoming posts, we’ll focus on some methods and tools for doing that kind of lean analysis, tools that can be used by developers, business analysts and project managers to get the beginnings of requirements from the customer in an efficient manner - “just enough”.

Another implication of this approach is how it affects project planning, budgeting, and scheduling.
In the comments for “The Waterfall Must Die“, Jon Terry wrote

…the survival of the waterfall has more to do with the business than IT. It fits budgeting processes. It enables us to get a locked down agreement between competing stakeholders. When you have a bunch of people trying to spend the same time/money, an agile development process gives them a bunch of opportunities to reopen closed discussions that they “lost”.

In this sense, your analysis and requirements gathering activities become a negotiation with your customer, instead of a collaboration. Your design documents become contractual agreements instead of a useful planning tool. It’s not an easy problem to solve. In the end, it is your responsibility to effect a change in the process. This will involve struggling to gain the trust of the business stakeholders, and to avoid getting stuck doing things the old way. It sometimes involves struggling against management’s desires to have all the proper paperwork. And there will inevitably be casualties. Sometimes, in your struggle to change things, you’ll lose.

Thankfully, it’s not an all-or-nothing decision. You can take your existing processes and mold them, introducing more “agility” a little at a time. In this discussion, Scott Ambler describes a “middle-of-the-road” approach, which will allow you satisfy many of the concerns of the stakeholders regarding requirements, budgeting, and scheduling, and still implement many Agile processes.

The basic trade-off we have to work with is this:

Would you like to have a clear, precise schedule/budget as early as possible, even if it results in lower-quality software that takes longer to build, knowing it’s a schedule/budget that we have a very slim chance of actually getting right,
or…
would you rather have greater confidence that the software will be delivered better (and faster), but it’s harder to say up front exactly when or how much it will cost?

There are some tools that we can use to come up with estimates, along with our experience, so we aren’t forsaking the estimation process entirely. But, like the phases in our process, we should get used to the estimation process being more fluid, more dependent on the things we learn and the rate at which we learn them. On the flip side of that, however, we can get started on development much earlier than traditional processes, like waterfall, allow. We can deliver individual features faster and earlier in the project.

Coming up: Analysis Models: Use Cases, User Stories, System Metaphors, and Boundary/Context analysis.

references: Going Round and Round and Getting Nowhere eXtremely Fast?
Another Look at Incremental and Iterative Development., Pascal Van Cauwenberghe,

Topics: Uncategorized | No Comments »

Collapse All

By indomitablehef | April 13, 2007

This is a “collapse all” macro for Visual Studio 2005. It gets annoying having to scroll up and down, expanding and collapsing folders. Sometimes, it would be nice to just tell Visual Studio to collapse everything, and start clean. This little macro does just that.

Topics: Uncategorized | 3 Comments »

It’s pronounced Co-Burn

By indomitablehef | April 11, 2007

Interesting audio interview with Alistair Cockburn over at itconversations.com, where he discusses agile development and some of its history. I enjoyed it, and recommend the book, too.

Topics: Uncategorized | No Comments »

Test Driven Development

By indomitablehef | April 5, 2007

Following a regrettable gap in posting (I’ve been busy buying a house these last few days), we’re back.

Test Driven Development is one of those things that sounds great when you first hear it. Climbing up on the bandwagon is relatively easy. Test Driven Development, however, is not. At least, it hasn’t been for me. I’m still unsatisfied with my level of mastery over it. Like any good ideologue, however, I am determined to make it work.

Actually, I’m not an ideologue about testing at all. I’m not one of those “everything must have a test” types. I prefer some kind of RTDD, or perhaps TFDWIMS (ReasonableTestDrivenDesign or TestFirstDesignWhenItMakesSense). Trouble is, it’s hard to know when to be strict about testing, and when not to. It helps to realize that Test Driven Development is not primarily about “testing” in the traditional sense. TDD is often sold solely on the basis of being able to do regression testing when something changes. The impression is that after the first release of an application, when the users request new features, they can be added by development, all the tests run, and the application will have no bugs. That’s all well and good, but it’s not the whole story…it’s not even the best part.

The most important reasons to do Test Driven Development have nothing to do with supporting future enhancements to an application, on a large scale. That is not to say that such projects will derive no benefit from a TDD approach, but if that is why you are planning to adopt TDD, you’d be better off investing in an automated testing software that can run usage scripts against your application, building detailed regression tests, and keeping them updated as you enhance your product.

No, TDD in the real world is really about something else, something smaller, something closer to the core of your software. First of all, TDD is a useful design tool. When implementing a feature, use case, or enhancement to your application, it is often illuminating to sit down and develop a Test Driven plan for how to proceed.

Let me give you an example. I’m about to begin working on an enhancement to an existing application, dealing with Patients and medical insurance Claims. The existing application already manages Patients, but it calls them “Members” (as in members of an insurance plan). The existing application has no Claims information in it, but I have a source database with the claims, related to Patients, that was supplied by the insurance plan (my client). I’m going to be making a lot more changes to this application in the future, and I intend to begin creating a rich domain model. I’ve already been learning about the domain and modeling what I’ve learned with business stakeholders.

My goals then, are as follows:

  1. refactor Member into Patient - Patient is part of the core of the domain model. I want to clarify that concept, and then build on it for future releases.
  2. add Claims data to the Patient, so that users of the application can see a Patient’s Claims history.

I’ve decided that I need a PatientFactory. The Patient class is going to get more and more complex as I build out the domain model, so having a Factory that knows how to build a Patient will be useful in the future, and will keep me from having to clutter up the Patient class with the details on exactly how it is built.

So, I’ve come up with the following Test Driven Development Plan.

  1. Write the PatientFactory Test Setup
    In the Unit Test’s Setup Method, add known Patients to database table, using SQL scripts.
  2. Write PatientFactory Test TearDown
    In the Unit Test’s TearDown method, add SQL delete commands to remove the known Patients added during Setup
  3. Write the PatientFactory Test: PatientFactory can retrieve a single known Patient by Id
    Notice that I haven’t even created a Patient or PatientFactory class yet. This test will fail.
  4. Implement PatientFactory.GetById (probably under a better name)
    Create the Patient Factory Class
    Create the Patient Class, converting the old Member Class into a Patient
    Re-use the existing data access code (happens to be ActiveRecord pattern) to retrieve Member/Patient data from the database.
    Implement PatientFactory.GetById - keep going till the test passes.
  5. Write Unit Test: PatientFactory can retrieve a list of known patients
  6. Implement PatientFactory.GetList method
    Until test passes.
  7. Implement the changes made all the way through the application to the UI, to test the refactoring of Member into Patient. Change the labels, docs, everything. Complete the refactoring of Member into Patient.
  8. Leaving out some steps here…testing/refactoring/implementing the update/delete features for Member/Patient.

Moving on to Claims:

  1. Still in the PatientFactory Test suite, Add to the Test Setup
    Insert Claims for known Patients into the database, using a SQL script.
  2. Add to the PatientFactory Test TearDown
    Sql Delete script to remove the claims we added during setup
  3. Write the unit test: Patient Factory can retrieve a single known Patient along with that Patient’s claims history.
  4. Implement the Claims class, update data access for Patient/Claims, add to PatientFactory code that will add the Claims to a Patient when a Patient is built. Stop when the unit test passes.
  5. Write Unit Test: Patient Factory retrieves a list of Patients (without claims), and then returns a single Patient selected from the list With Claims.
    So, essentially, we are lazy loading Claims History.
  6. Implement the “lazy load” feature in the PatientFactory
  7. Implement Claims all the way through to the UI, web controls, docs, etc.
  8. Implement sorting for the Claims History in the UI

Thinking through the features I intend to implement, using a Test-First approach, can actually help clarify and simplify your design decisions, and result in a useful checklist of sorts to help you move quickly through the development of features.

The real raison d’être for Test Driven Development is what happens next. Now that I have the beginnings of a test suite, and the beginnings of my core domain model, I will begin the process of refactoring. Notice that I did not write unit tests for displaying Patients, displaying Claims, or sorting lists of Patients or Claims. These things are trivial. The emerging domain model, however, is not. In future iterations, I want to add relationships between Patients and Providers, Care Plans, Risks, Interventions, and Outcomes. As I grow this domain model a little at a time, I will write the tests first, add new domain concepts, and when I’ve finished, run the domain layer unit tests I’ve created to validate the correctness of my core domain. As the model matures, I may well learn that some things that I once thought “belonged” to a Patient are really the child of some other class in the model. When that happens, I will restructure my tests, refactor my domain layer to match my new understanding, and re-validate the model through running the tests.

Test Driven Development enables effective refactoring of the domain model to a richer understanding of the domain. Use it for that and don’t try to write tests for every trivial detail. When you write your class first, then use your Unit Testing software (Visual Studio, NUnit, others) to “Generate Unit Tests”, it will generate a test class that contains test methods to check to see that every property get/set in your class works. What a complete waste of time! Write your test first, test only the important stuff, and get on with building something useful.

Some Reading on Test Driven Development:

Introduction to Test Driven Design (TDD) at AgileData.org
Extreme Testing
For anyone using Visual Studio Team System’s testing features, a very useful little tidbit.

Topics: Uncategorized | No Comments »

« Previous Entries Next Entries »