Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

According to Martin Fowler classical article, there are two types of verification: state and behaviour verification. At the same time I often see people telling about implementation vs. behaviour verification. So I guess we speak about pretty same stuff here and "state" in the first classification is "behaviour" in the second; "behaviour" in the first equals to "implementation" in the second.

What I don't like is that "behaviour" word appears in both namings but on contrary sides which causes a lot of confusion.

Which naming do you prefer?

share|improve this question
up vote 2 down vote accepted

These two approaches use different meanings of the word "behavior".

The first one (behavior vs. state) is based on a design mindset that views programs as a collection of states and transitions between those states. In such a model, "state" is a static thing; if you had a computer that you could freeze or single-step (like those back in the 1970's), then you could stop it at any time and inspect its state (the values currently stored in its register and memory), but to observe its behavior, you need it to run. It is quite common to visualize the dynamic aspects of a (part of a) program as a diagram where boxes represent states, and arrows represent transitions between those states.

The second meaning offsets functional characteristics of the program (what does it do?) against technical details (how did they make it do what it does?). This separation is fairly common; many methodologies split the design phase into functional and technical design parts. In this mindset, the behavior of a program is what it functionally and observably does, from a user's perspective (e.g., when I click this button here, a bunch of dummy text appears above it); the implementation, by contrast, is how it's done (e.g., there's this HTML form with a submit button, and the server-side script reads the POST request fired by that script, calls a web service to generate some lorem ipsum, and inserts it into the form which then gets sent back in the response).

The first meaning is interesting, because deciding what you want to model as state (data) and what you want to follow implicitly through behavior has a huge impact on any software project. Making your data too rigid makes you inflexible to future change; putting too much information in your logic and too little in your data makes for an unmaintainable mess of complex logic.

The second one is important, because it allows you to specify requirements without making any technical decisions (yet). If the functional requirements are unambiguous and clear, you can then verify that the technical design meets the functional requirements, and later, during acceptance testing, you can also verify that the actual product meets the functional requirements (which is far more important than meeting the technical requirements: who cares if you haven't used XML, as long as the thing does what it's supposed to do).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.