Software Debugged

In this article I want to look at the essential characteristics that objects have, namely those of state, behaviour and identity. This article follows on from my my What is an Object? article of a while ago, when I offered the following definition of what an object is:

An object is a physical manifestation of a type, that executes the responsibilities of that type

That definition is just the first step and isn’t very useful by itself. This article continues a miniseries that began with my What is an Object? article. In this miniseries, I want to dig deeper, so that the above definition makes sense and thus becomes useful. I will write future articles about each of state, behaviour and identity individually, and in more detail. For now though, in order to get started, I will give just a short summary on which to build later:

State is the informational content of an object. An object’s client (usage) code perceives the object’s state as the values of its publicly exposed properties.

Identity refers to the properties of an object that make it unique; that is, the properties that distinguish it from all other objects. An object’s identity is expressed through a subset of its state.

Behaviour is the activity of an object, that is to say it is the way the object responds in interactions with its client code. Such interactions may be in the form of how the object responds to requests other objects make of it, and the notifications of changes to its state that it sends out to other objects.

That builds a little bit more on the above definition of an object, and, as I said above, I will build on it with more articles in the future in order to give a more complete picture. Unfortunately, like many aspects of software development, object oriented design and programming is not a simple topic.

I’ve written a few articles about unit testing on this blog, but so far they’ve been about how to go about doing so and what supporting libraries/frameworks are available. Now I want to look at why unit testing is a good idea. In particular, this article will focus on the business perspective.

Many software developers embrace the unit testing of code with enthusiasm. Unfortunately though, there are many who see it as something that will just hinder them in getting their work done - after all, they will have to write significantly more code, won’t they? It is even more unfortunate that many managers see things the same way. So, why unit test, given that developers will indeed have to write significantly more code?

The fact is that, from a business perspective, unit testing earns its keep on the cost/benefit scale. The 1988 paper "Understanding and Controlling Software Costs" by Barry Boehm and Philip Papaccio states:

…the cost of fixing or reworking software is much smaller (by factors of 50 to 200) in the earlier phases of the software life cycle than in the later phases

The authors also provide references in support of this statement. Now look at the numbers: assuming the least worst case, catching an error early make it cheaper to fix by a factor of fifty. Compare this with the amount of effort needed to write a unit test - and remember this is the least worst case. It seems that unit testing is definitely earning its keep! Unfortunately, my research suggests there is a lack of recent data published on the web in this field. However, although the paper I have cited is quite old, it is hard to imagine that things have improved in the light of today’s technology. In fact, things are likely to be worse because computer systems are much more complex, as they attempt to solve much more complex problems.

Unfortunately, unit testing will not guarantee completely bug free code. Somewhere, something will get missed. It is likely, for example, that unit test coverage will miss some aspects - corner cases in particular - of the code. Despite this, the evidence suggests that it does contribute significantly.

At the end of my previous article Pros and Cons of Using the C assert Macro for Unit Testing in C/C++ I promised to follow up with an article summarising the popular unit testing libraries/frameworks. In this article I will give that summary:

• For the .NET languages there is NUnit. Although the source code is written in C# it can be used to unit test any .NET language. Sample code is supplied for C#, .NET C++ extensions (both managed and CLR) and J#
• JUnit was developed for the unit testing of Java code and was the inspiration for many unit test frameworks that were to follow. JUnit is Java specific
• For Python there is the Python Unit Testing Framework or PyUnit for short. PyUnit is part of the Python standard library as of Python version 2.1
• For ISO standard C++ there are several unit test frameworks/libraries around. Probably the most popular are CPPUnit, The Boost Test Library and Aeryn. CPPUnit was an attempt to “port” JUnit to C++, whereas The Boost Test Library and Aeryn are in keeping with idiomatic modern C++

That concludes my roundup. Please comment if you feel I’ve missed a library that should have been included. Note that all the above libraries are open source (and in the case of Python, Python itself is open source).

Update

(Wed 11th Feb, 2009)

Thanks to Alan (see comments, below) for drawing my attention to SUnit - the unit testing tool for Smalltalk.

This is a short follow-up to my recent article A Very Simple Introduction to Unit Testing. In that article I described the development of a very simple unit test for a very simple C++ class. To do this I used the C/C++ assert() macro, saying the following about it:

"…although assert wasn’t originally intended for unit testing, it makes a simple but effective tool for doing so without the need to look outside the language’s standard library."

I’d like to thank John Crickett for - in an offline conversation - pointing out that there are some things that I should have made clearer. Although - as I said - assert is very effective for unit testing without the need to look outside the C/C++ standard library, it does have its shortcomings. Let me summarise the points for and against.

Points for:

1. There is no need to look outside the language’s standard library, so programmers can start unit testing without the overhead of having to set anything up
2. If an assert fails, the program stops running. Therefore, the programmer must fix the problem before continuing. Note this is also a point against (below), but the reasoning is different

Points against:

1. It is only available to programmers working in C and/or C++ (obviously)
2. You can only test the debug version of your code
3. If an assert fails, the program stops running. This makes assert unsuitable for unit tests that are run in any kind of automated mode - for example, some automated build systems run the unit tests immediately after the applicable unit of code has been built

Therefore, based on the above, I suggest the use of assert is suitable for programmers unit testing in the following situations:

• Learning to write unit tests (see 1, under points for), either as part of a formal training course or otherwise
• Unit testing in a development environment which has no unit testing culture (again, see 1, under points for). Programmers can develop their own unit tests without the need for support from their development environment. For example, they may not be allowed to - or even able to - install libraries other than those officially used by the development group

Thinking about it now, my original assertion (pun intended) was over zealous, in that I didn’t qualify it with the context I was thinking in at the time. This article should serve to set the record straight.

The question remains: what should be used in those situations where assert is not sufficient? I was going to summarise some of the alternatives available in C++, but it now occurs to me that such a summary would really be out of place in this article. This is because - going back to its predecessor A Very Simple Introduction to Unit Testing - I only used C++ in the first place so I could use assert, and I wanted to use assert in the first place for simplicity. That is to say, the discussion here is about the suitability of assert. Therefore, I’ll take the approach of coming back to this topic soon, and write a summary of the available unit testing libraries/frameworks for several popular programming languages. When I’ve done so, I’ll post an update here with a link to it.

Much present day commercial software development - probably the majority of it - claims to be object oriented, and at the centre of object oriented software is the object. So, what is an object? Unfortunately, the word object seems to have joined the ranks of the buzzwords. It seems to have become one of those terms that gets banded about, without its users ever stopping to ask themselves if they really know what one is. This has resulted in a lack of design discipline that I believe has strongly contributed to the poor design of many software systems. In the remainder of this article, I will give my answer to the question that its title poses.

To get to the answer, we need to step back and think about why we use objects. I’d say it’s because they enable us to represent concepts from the real world in software. These concepts might be real life things that we import from the problem domain, or things that exist only in the computer solution, for example a message receiver or a process. An object exhibits a set of operational semantics representing a concept in an abstract form. I will refer to these semantics collectively as the object’s type. It follows that a type is an abstraction of a real world concept in a software design model.

Types are therefore the role players in software designs, and they play their roles by assuming responsibilities. A type has closely related responsibilities that are grouped together to collectively make up the role played by the type. Now, having said all that, the original question was: what is an object? The above discussion leads to the following definition:

• An object is a physical manifestation of a type, that executes the responsibilities of that type

The understanding of what an object actually is only serves as a starting point for using objects effectively in software design, but I also think it is is an essential starting point. This article is rather brief because it has a very narrow scoped, its purpose being to provide an answer to a very basic question. I hope to follow up with more broadly scoped articles fairly soon.