• Clear objectives:  Running tested software that meets our customers´ needs, and
• Real support:  Training and coaching of the Agile techniques and its mindset, free of budgetary impact.

It really is that simple, I think, but still far from easy.  The first point should be obvious, but the way Agilists do it may not be.  The second point makes all the sense in the world for me, but I don´t know about my managers.  Mostly, I feel I´m on my own learning the Agile way of crafting software.

 

Anyway, go read the whole thing.

I am going to start my musings on class invariants by pulling an old trick out of my hat.  This is the timeless trick, it seems, of getting out the dictionary and looking up a word I want to muse on.  Since I haven´t consciously employed invariants in my classes I thought this could be a good place to start, as I am exploring this idea, and how I might use it, instead of expounding on my real experience with it.  Yet again, it was reading something in Pragmatic Unit Testing (C#) that prompted me to blog about it.  My Webster’s Encyclopedic Unabridged Dictionary has the following to say:

invariant

n.       1.  Math.  A quantity or expression that is constant throughout a certain range of conditions.

This is pretty much what I expected, as my understanding of a class invariant has been that it´s an expression that should evaluate to true before and after every method call of my class.  It might evaluate to false if you checked it in the middle of a method call, but it should never be false outside the boundary of the class’s methods.

An example of explicit usage of a class invariant is shown on p. 61 in Pragmatic Unit Testing.  It shows a minimal implementation of a Stack that uses a String array and an integer that indexes into the array.  So, when you pop from it the integer is used to index into the array thus returning a String from it and then the index is decremented by one.  There are no checks for an empty stack or a stack overflow, so the authors suggest adding a method called CheckInvariant that throws an exception when the invariant rule is broken.  They also suggest having this method public so test code can call it to root out potential errors in the coding of the Stack class.  Good advice?  I think so, however I suspect many would feel uncomfortable having a public method only for testing.  I´ve been feeling less and less uncomfortable with publicizing some methods that would otherwise be private if not for their need in testing. 

This example uses a Stack to present the usage of invariants, and it is very easy to see the need for it there, but what about other types of classes?  If I look back on my coding career I must say that I don´t spot that many classes that could be retrofitted with a CheckInvariant method like in the example above. However, I suspect that this might be due to the immaturity of my designs more than anything else.  If my classes had been less procedural and more like elements in a business domain language, then perhaps invariants would have been a better fit?

I´ve heard of the use of a class invariant, the talk of pre- and post-conditions, since I first went to a programming class in college, but I´ve never really connected with its message.  The only programming language I know of that supports it intrinsically is Eiffel which I have never used, but Eiffel´s author Bertrand Meyer obviously felt strongly about their benefits.  I´ve heard a lot of talk about defensive programming, which I practice, and to me that seems to be much the same thing.  Well, maybe not quite, since in the case of an invariant you are not only defending your class against its clients but also against the code inside the methods of the class.  That is to say, on the one hand there are conditions that the users of a class could break if we don´t defend ourselves, and on the other hand there is code we put in our methods that could possibly cause the invariant to be broken by the time the method exits.  But, the rigorous, disciplined work of always identifying an invariant in a class just doesn´t feel like a mandatory coding tool/method to me - certainly not like unit testing.  However, when I think about it some more I see that my unit tests probably find the elements that make up the invariant in my classes, if there is one, incrementally as I TDD my way to an implementation.

This is a somewhat rambling post and the reason is that I don´t seem to have a proper point to make or a conclusion to draw, since my musing on this hasn´t awarded me any new insights here L  I think I will probably experiment with this some more and see if that gives me more closure, as they say in the movies, because this post certainly hasn´t!

It´s been pretty hard getting any blogging done these last few days as we´ve been having some pretty good weather here in Reykjavík (good for us is 15 C and sunny ;-)).  There are a few things that reading the Pragmatic Unit Testing (C#) book got me thinking about and I´ve been meaning to write those up.  I want to start with the subject of mock objects - what they do for me, my experience using them and what I have learned from that.

For starters, in a sentence, what are mock objects?  For me, mock objects enable unit testing of classes that have dependencies on other, hard-to-setup classes.  OK, that´s a sentence, but it might not say very much ;-)  To elaborate, whenever I have classes that use resources like the database, configuration files, web services, and so on, I like to be able to swap those out for something simpler at test-time.  I´m not testing if the classes that access these resources work, I expect them to work, so I want to use objects that mock their behavior in a variety of ways.  For instance, if my class under test uses a class that retrieves, say, Student classes from the database I might like to test my class´s behavior when it gets 0, 1 and 2 instances of the Student class back.  Also, I probably want to test how my class behaves if it gets an exception thrown from the database class.  With mock objects I can set the database class up with all these behaviors and more.

Now, most of my experience with mock objects has been with the manual kind.  That is, say I´m using a DAO (Data Access Object) called StudentDAO in class StudentService and I want to test my StudentService class without hitting my data store.  In the past I´ve created a new class in a folder called Mocks/Dao named MockStudentDAO and overridden the methods I want to mock and provided some methods for setting the mock up with test data.  A lot of the time I would also provide ways to set Expectations on the mock so I could have the mock verify that the mocked class was used in the way I expected it to be used.  There is a library available for .NET that makes creating your own mock objects somewhat easier called DotNetMock, which I´ve used with pretty good results.  In an abbreviated form a manual mock solution looks something like (in C#):

class MockStudentDAO : StudentDAO, IVerifiable {

       private ArrayList _students = new ArrayList();

       public void SetupStudents(ArrayList students) { _students = students; }

       public override ArrayList FindAll() { return _students; }

       // Implement IVerifiable, and maybe methods to set expectations …         

}

class StudentService {

       private StudentDAO _dao;

       public StudentService(StudentDAO dao) {

              _dao = dao;

       }

       public ArrayList GetStudents() {
              ArrayList students = _dao.FindAll();

// do some calculations, sorting, filtering, … before returning the students

              return students;

       }

}

[TestFixture]

class StudentServiceTest {

       [Test]

       public void GetStudents() {

              MockStudentDAO mockDAO = new MockStudentDAO();

              mockDAO.SetupStudents(GetSomeTestStudents());

              StudentService service = new StudentService(mockDAO);

              ArrayList students = service.GetStudents();

// do some assertions on the list

// if I set some expectations the next line will verify them

mockDAO.Verify();

}     

}

This means I don´t have to have a database ready; I don´t have to set the database up with the right type of data or clean it up after I finish.  However, for each of these resource-accessing classes like the StudentDAO I have to code up its partner the MockStudentDAO for this to work!  My experience with this type of manual mocking has made me consider alternative ways of creating my mock objects to avoid having all those MockXXX objects in my test project.  This is where dynamic mocking comes in.

Instead of creating mock objects statically and giving them their own source file, there are libraries that enable you to specify the behavior that you want mocked and have the library create mock implementations of those behaviors at runtime.  For this we can use NMock in .NET or jMock in Java.  Let´s see how the previous code sample looks like with dynamic mocking, but let´s use Java this time, since I have used jMock but not NMock.  The StudentService class looks exactly the same in Java as it does in C# so I´ll go right to the test:

import org.jmock.*;

class StudentServiceTest extends MockObjectTestCase {

public void testGetStudents() {

              // set up

              Mock mockDao = mock(StudentDAO.class);

              StudentService service =

new StudentService( (StudentDAO) mockDao.proxy() );       

              mockDao.expects(once()).method(“FindAll”)

.will(returnValue(GetSomeTestStudents());

              ArrayList students = service.GetStudents();

// do some assertions on the list

       }

}

I find this method far less cumbersome than the former.  No need to create separate source files and I like the descriptiveness of the way you set up the behavior of your mock.  Also, jMock supports mocking of interfaces and concrete classes.  I know, I should probably always be programming to interfaces but I don´t and I like that jMock helps out with that too.

In conclusion, my experience using mock objects is that they are an indispensable tool to have in your arsenal, but I´ve also learned that you can overdo it with their use.  Now, each time I feel the need to use mock objects I stop and consider for a moment if there is any other way for me to test my class.  One reason for curbing your enthusiasm with the use of mock objects, is that because you are mocking behavior of some existing class you need to do it correctly which means you can screw that up and then your tests work, but the class you´re testing might not once it uses the real thing.  That stated, I encourage every programmer to use mock objects where appropriate as it can solve some sticky testing situations better than any other method can.

I heard this really funny analogy in a podcast of Kent Beck´s presentation recorded at the Developer Testing Forum in Palo Alto, CA in November 2004 that is downloadable from ITConversations.  Kent is talking about how developer testing can help you ship healthy software and he mentions this analogy that he heard about software releases at Microsoft.  Here´s my version of Kent´s account:

Your software is Jello.  People are constantly making changes to it, so it´s quivering, shaking, all the time it seems to be moving and hardly ever staying still.  So you watch it intently and when it stops moving for just a second – that´s when you ship it!

How hilariously sad is that ;-)

The last year or so I have been playing around with programming in Ruby. I decided to check it out after reading Martin Fowler´s views on it.  That led me to read the Pragmatic Programmers´ book Programming Ruby (highly recommended!) and now I´m using it for some pet projects of mine and plan on using it more in the future, especially when automating some tedious work.  Also, I have experimented with Rails and will surely do more of that as soon as I get my hands on the Pragmatic Programmers´ upcoming book on this Ruby web development framework.  Anyway, I really like programming in Ruby, although I´m waiting for a really first-class IDE for it (I currently use a plugin for Eclipse), but Ruby only indirectly affects what I wanted to put forth in this entry.

When reading Pragmatic Unit Testing the other day I came across a phrase that the authors claimed programmers often use as an excuse not to write unit tests (I happen to have heard this phrase once or twice at work ;-)):

            “But it compiles!”

The authors go on to say that “no one really comes out with this as an excuse, at least not out loud.  But it´s easy to get lulled into thinking that a successful compile is somehow a mark of approval”.  This brings me to my point which is that when you are using a dynamically typed programming language, as Ruby is, this excuse evaporates.  There is no compilation stage; the program either runs or it doesn´t!  This, in my mind, is a good thing because I write unit tests religiously so I get the flexibility of dynamic typing in Ruby and use my unit tests to catch syntax errors for me.  This is, by no means, a novel idea and has been discussed before by the great Uncle Bob, but it was just a combination of my recent Ruby episodes and reading the book that I was reminded of this powerful synergy between dynamic languages and automated unit testing.

In Stooping low, in order to... Rajesh Babu writes about some sentiments that he has heard uttered many times in his career:

“We know that this work is not interesting or life-changing, but if we can do this well, then the client will give us more interesting work.”

I have met with these same sentiments myself on several occasions during my comparatively short career as a software developer. Hearing them has evoked the same feelings Rajesh goes on to describe later in his post:

“I find it hard to take the suggestion that we need to do things that we don't like in order to get things that we like doing.”

Now, I perceive Rajesh’s core message in the post to be a hypothesis that basically says that a software shop with customers that are thrilled with the software service they receive, should not have to stoop low with uninteresting projects to get more exciting work. In some ways I feel the same way. Even so, my contention is that you are always going to be handed projects that at first seem “not interesting or life-changing”. Every customer that I have been involved with on more than one project has asked me to create a piece of software that means a lot to his or her business even though, on the face of it, creating that piece of software looks rather dull to me.

What I have done in these circumstances is to make the project interesting. Maybe not life-changing, but at least a whole lot more interesting than it seemed to be at first glance. The way I´ve done this is to take a good look at this dull-looking project and think to myself: “What element on this project, technical or human in nature, piques my interest or is already on my long list of things of which I want to enhance my knowledge?” When I spot this element, or, more likely, these elements, I find that I can be passionate about the whole project because I truly have a vested interest in it.

In the past for me these elements have been xUnit unit-testing, mock objects, O/R mapping, the .NET Framework, CRC cards, design patterns (who hasn´t gone patterns-crazy after reading Design Patterns ;-)) and build scripts, to name a few examples of technical elements; on the human side there have been methods suggested by the Agile community, like daily stand-up meetings, pair-programming and retrospectives.

The subtitle of chapter 7 in David Schmaltz’s great book The Blind Men And The Elephant reads: “No one is apathetic except in pursuit of someone else´s goal”. I find that this dovetails nicely with what I just talked about above. This is why I start by identifying my own goals for each project.

David says more that relates to this discussion:

“Most projects are not pursuing awful objectives. Many that are pursuing disagreeable goals could redefine their targets into really alluring ones. A better question? “How do we engineer a mutually self-interested effort?””

So I say again, make the project interesting. For each project try to, as David says, “engineer a mutually self-interested effort”. Something that you feel you can be really passionate about and you think will benefit the project in question.