I find that in order to get natural feedback early in a development cycle, you need to write so many interdependent bits of code to get something actually working that any mistakes you made along the way are buried in a mountain of spatial complexity. By testing at a lowish level along the way, you don't have to wait until there's a button to press to see if things are working as expected. Long feedback cycles make for tedious debugging sessions. I consider testing more useful as an aid for authoring code than as proof that it works after the fact, but that's a nice side effect. It also forces good separation of concerns (monolithic procedures are difficult to isolate). I don't worry about 100% code coverage; I test what I need to test to feel confident my code is working.
Edit: I also write a lot of throw-away tests as I go. I find that the easiest way to figure out how third party libraries work is to write tests against the documentation. If you find something unexpected that way, you can be pretty sure it's somebody else's fault.
Interesting. We don't do much agile, and do a LOT of up-front design. Mostly out of necessity (you can't create secure software using scrum, kanban or XP). Defining the architecture before we start is where we do what you describe as doing with tests.
Comments
I find that in order to get natural feedback early in a development cycle, you need to write so many interdependent bits of code to get something actually working that any mistakes you made along the way are buried in a mountain of spatial complexity. By testing at a lowish level along the way, you don't have to wait until there's a button to press to see if things are working as expected. Long feedback cycles make for tedious debugging sessions. I consider testing more useful as an aid for authoring code than as proof that it works after the fact, but that's a nice side effect. It also forces good separation of concerns (monolithic procedures are difficult to isolate). I don't worry about 100% code coverage; I test what I need to test to feel confident my code is working.
Edit: I also write a lot of throw-away tests as I go. I find that the easiest way to figure out how third party libraries work is to write tests against the documentation. If you find something unexpected that way, you can be pretty sure it's somebody else's fault.
Interesting. We don't do much agile, and do a LOT of up-front design. Mostly out of necessity (you can't create secure software using scrum, kanban or XP). Defining the architecture before we start is where we do what you describe as doing with tests.