I never used to like unit testing. I always thought it increased the amount of work I had to do.
Turns out, that's only true in terms of the actual number of lines of code you write and furthermore, this is completely offset by the increase in the number of lines of useful code that you can write in an hour with tests and test driven development.

Now I love unit tests as they allow me to write useful code, that quite often works first time! (knock on wood)

I have found that people are reluctant to do unit tests or start a project with test driven development if they are under strict time-lines or in an environment where others don't do it, so they don't. Kinda like, a cultural refusal to even try.

I think one of the most powerful things about unit testing is the confidence that it gives you to undertake refactoring. It also gives new found hope, that I can give my code to someone else to refactor/improve, and if my unit tests still work, I can use the new version of the library that they modified, pretty much, without fear.

It's this last aspect of unit testing that I think needs a new name. The unit test is more like a contract of what this code should do now, and in the future.
When I hear the word testing, I think of mice in cages, with multiple experiments done on them to see the effectiveness of a compound. This is not what unit testing is, we're not trying out different code to see what is the most affective approach, we're defining what outputs we expect with what inputs. In the mice example, unit tests are more like the definitions of how the universe will work as opposed to the experiments done on the mice.

Am I on crack or does anyone else see this refusal to do testing and do they think it's a similar reason they don't want to do it?
What reasons do you / others give for not testing?
What do you think their motivations are in not unit testing?

And as a new name for unit testing that might get over some of the objections, how about jContract? (A bit Java centric I know :), or Unit Contracts?

  • 14
    What's in a name? that which we call a rose By any other name would smell as sweet; -- Shakespeare, Romeo and Juliet, c.1600 – Steven A. Lowe Jan 3 '11 at 17:28
  • 8
    I don't know if you are on crack. I have never tried crack, or being you. – Tim Post Jan 3 '11 at 17:35
  • 1
    I think that ideas get attached to words mostly because of the ideas and attitudes attached to them, not the words. I remember finding out that the Spastics Society had changed its name to Scope, because the name was associated with prejudice. I remember because it explained why I'd heard kids calling each other "scopey" earlier that day. If you want to change the attitude, focus on the attitude, not the name - obsessing on the name is just timewasting. – Steve314 Jan 3 '11 at 17:47
  • 2
    Design by Contract: en.wikipedia.org/wiki/Design_by_contract Has a specific conotation, and unit tests aren't it. If I see something with Contract in the name, that (and interfaces) is what my brain associates with it. – Berin Loritsch Jan 3 '11 at 17:50
  • @Steve314 Scopey. Like it. :) I think in this case, the word testing is already defined, and thus renaming unit tests to an undefined term would be better. Contract can't be it due to the mentioned 'interface'. How about 'create better programs faster' or CBPF. – Will Jan 3 '11 at 17:57

Am I on crack or does anyone else see this refusal to do testing and do they think it's a similar reason they don't want to do it?

The word testing in unit testing makes people think this is integration testing or user interface testing because thats the only sort of testing they've ever done. It like putting java into javascript.

When something has a bad name and it affects people's thinking about it it's called a framing error. Framing errors tend to be superficial-- people are smart and can see through all sort of bad names, bad metaphors.

What reasons do you / others give for not testing?

Dependencies that are difficult to mock/fake/

What do you think their motivations are in not unit testing?

Unit testing has a modest concept count and a non-trivial amount of work needs to be done before one stops writing bad unit tests and starts writing good ones. As people get better at explaining what unit testing is, adoption will increase. In my experience, unit testing has a near magical effect on productivity and code quality. But it didn't start out that way. I originally used unit testing frameworks as a convenient way to write integration tests.

  • Great points. Trying to explain why you would 'test' a simple get method is hard, explaining why it's contractually important to the stability of all the rest of your code that the get method always returns what you expect is an easier argument to make – Will Jan 3 '11 at 17:40

The concept of a name change has already been proferred. It's called Behavior Driven Development. The guys who came up with that noticed much of the same arguments plus the unnatural fit to test something that isn't created yet. Instead, their concept is to write an executable specification (which is what TDD is really about anyway).

I've noticed the same pushback. I've also noticed that a number of people just don't know how to write unit tests. They are lacking in the scientific process disciplines, and merely use the unit test framework as a way to wire everything together and start the debugger. In short, they aren't truly improving the use of their time. I can't tell you how many unit tests I've seen that were several tens of lines long (30+ lines) and not one assert statement. When I see that, I know it's time to work with the developer and teach them what an assertion is, and how to write unit tests that actually test.

  • 2
    Executable specification probably predates TDD/BDD/Agile/XP. It might be as old as CMMI. It used to be a co-fad with UML when people thought that UML is the language for writing ES. – rwong May 8 '11 at 16:13
  • BDD, like TDD, is an approach to testing, not a kind of testing (functional v integration v unit v acceptance). The author is asking specifically about a "better" name for unit testing. – ybakos Jul 22 '12 at 23:32

Contracts are called "interfaces" in most cases here. Having unit tests doesn't guarantee the contracts per se, as you can change the tests as well, so you don't actually know that you can use the new version of the library just because the library is tested. You need to test the code that uses the library too. That's not different from any other unit testing, so I don't see why that would need a new name.

I think, like you, that most people reluctant to do tests do so because they think it's more work and no use.


I'll tell you why I don't like TDD: its not because I can't see the value in it, or recognise the benefits of a test suite that I can run to verify all my code after each modification.

Its because I don't need it. I'm a pretty old-school dev, when I were a lad we didn't have no fancy integrated debuggers with edit-and-continue to write code in, and a compile could take quite a long time so we had to get things right, right from the start. Given such training, I don't really see that writing a load of unit tests would make me more productive or my code more bug-free.

I do test my code, but as I've always done, this has been on the entire thing rather than the individual pieces. So maybe I do have 'unit tests', but they're rather more coarse grained.

So that's my reason. I can't see the need for me to do it. The code I produce is good enough and if that's the case, why should I change my processes to fix something that isn't broken?

  • You must write very simple code then. The amount of reachable states in most modern systems mean that to do end-to-end testing would take the lifetime of the universe - testing two pieces each with 4bits of state takes 16 cases to test each, or 32 test cases in total; made into an end-to-end system gives 8bits of state or 256 test cases to cover all states. Personally, I'd rather do 1/8 the work. – Pete Kirkham May 25 '15 at 20:59
  • 1
    @PeteKirkham the corollary of that is that you need to write a large number of unit tests and then also write the integration tests to make sure the unit still work with each other. The places I worked that were very fond of unit tests spent so much time writing (and maintaining) them that they dwarfed the codebase, and the amount of work they did was tiny in comparison to what I achieve outside that environment. Nothing is a magic bullet, I recommend trying to find a more pragmatic approach that gives you both test coverage of the important bits while also producing something. – gbjbaanb May 25 '15 at 22:05

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