http://www.testearly.com/2006/10/03/test-first-or-second/

“Teams new to developer testing should ensure they can walk (i.e. write tests for non-trivial logic) before attempting to sprint (i.e. write tests first). Once the team is comfortable writing tests and understands how to test difficult scenarios like dealing with databases, etc, then perhaps a test first stipulation can stick. But by then, a developer testing process has most likely already stuck.”

xUnit Test Patterns also list testing skills in the order a developer would ideally learn them (single assert through to non OO legacy code).

It’s not all that bad though. If you take a test-infected developer and pair them with another developer there’s always a chance they’ll take an interest. Or at the very least they’ll better understand why other developers like to test first. So there is hope.

As you say, it requires discpline and also creativity. It is not easy to comprehensively test your code.

Also, code-first tesing is unsustainable, boring and a massive burden on developers that take pleasure from building stuff and not really testing it. (Personally, I feel that testing is part of the building process.)

So basically, if you’re not writing tests first, its unlikely that you will write them at all. And even if you do write the tests later, its unlikely that the same level of attention and due diligence will be applied given that the code is already cut and out there.

Hmmm…not a very nice picture

I think writing tests after the code is also a big issue for many developers. The code is what’s required so why add to the effort by creating unit tests?

Unit testing tends to be the sticking point too. I meet very few developers who don’t see that value in automated end-to-end tests.

Unfortunately I think that’s the reason developers who try writing tests go off testing in general. They do the obvious thing of writing lots of end-to-end tests that end up being slow, break easily as the system changes, and end up as enormous maintainence burdens.

For most of the parts, I agree with you. I mean, we all (developers) would probably agree with you – that tests help maintaining the code, verify its accuracy, etc etc.

The problem is : we don’t do tests. It’s a fact. You’ve stated it.

Stop here.

Most people jump over this quickly, and just blame it into lazyness, lack of time, whatnot. I think it’s a psychological barrier, that keeps us away from testing and I think there is probably a good reason for that. I’m not sure how to put it, but let me describe my stance.

I do testing. I don’t write tests. This is fundamental difference for me. Maybe because I’m not “just developer” in my heart, but always trying to step aside, and look at everything (that is : project, code, functionality, approach) from a different angle, in a different light. There are always psychological issues here as well. While graduating from university, having master degree, I come from the world, where people don’t give a s*** about “stuff around”. They just care for a) design b) look c) fun d) functionality. That is, again, while having good knowledge about design patterns, etc, I’m not really code maniac. I just don’t care. I like those DRY, YAGNI, KISS principles. I believe that creating a software is a job like everything else and should be treated as everything else. However, due to insane amount of abstraction you need to deal doing that, a lot of developers completely forgot why they are doing what they are doing, focusing instead on “stuff around”, technological jargon and mumbo-jumbo like : “let’s have a framework, let’s optimize, let’s write our own testing engine, let’s do this and that, and MAYBE then we will go for real app. Well, no. Let’s spend a month on writing tests to be sure that we understand our client”. This is ridicolous approach for me. The best way to understand client is by using techniques that visualize : wireframes, sketches, demos, prototypes – because that is the exact context the future app will be running within. Not tests.

In my world, people value their time and believe that human will be always way better than computer in perception, intuition, recognition, etc. Then again it is always a human who writes the test. Writing another big chunk of code to support another chunk of code is going into endless loop for me. I want to create application people want to use. If it takes a lot of time, let it be. I can take that risk. My testing will be done by me – I will discover the bug on my own and fix on my own. Tests are not helping – they just alert that something is bad. They can more-less point you to the place that is broken. But you still need to devote time and find a solution and fix the bug. And, honestly, the amount of time to hunt the bug is in 85% of cases counted in minutes. I don’t need tests for that.

I don’t write tests because :
- the reasons you’ve mentioned, with the exception of first and last, plus
- It’s ultrahard to write a good test. I just don’t feel comfortable with struggling with piece of code that is useless in terms of functionality.
- I think that they are doing fine only for simple blackbox testing. If you are going to use some mock objects, test on a bit higher level – you are knee deep in the swamp and you are not going to escape quickly.
- I tend to focus on things that influence the user experience. You can’t easily test that. Ok, you can test UI to some extent. But the routine you need to do is so boring and incomplete, that It’s really faster to launch the app and notice instantly “bah, button is missing”.
- I have never been a part of project, that was toppling over because of lack of tests. There were bugs, sure. There were fixes. There was some time spent on fixing. All went well. Noone complained. Sun is still shining.
- I would never thing that tests are a way to communicate within the group. Sorry. We are people. We communicate through talking, showing pictures, writing documents, examples. Not by computer code. I don’t want to look at it.
- I believe that at certain amount of skill, discipline and awareness, you are able to avoid 70% of the bugs. That 30% are really complex and evil cases, you would probably not discover in yout tests as well (because you first need to THINK and IMAGINE such situation).

Phew, got to get it off my chest