I develop software in a research environment, turning PhD students code into production quality systems. I think there are a lot of developers out there who don

I develop software in a research environment, turning PhD students code into production quality systems. I think there are a lot of developers out there who don't write tests, or only write tests because you're "supposed" to (as evidenced by the popularity of the Stack Overflow question "Is Unit Testing worth the effort?" http://stackoverflow.com/questions/67299/is-unit-testing-worth-the-effort http://stackoverflow.com/questions/67299/is-unit-testing-wor...). They don't see the benefit for themselves, but like proper documentation, it's mainly a courtesy to other developers. What I wish I was told about testing is that if you modify your workflow, it benefits YOU as well as your colleagues. Without testing, trying out a feature means: 1. Make changes. 2. Restart application or server (possibly refreshing page). 3. Go through a series of clicks or keystrokes. 4. Didn't work? Go to step 1. Steps 2 and 3 can take a lot of time, and you'll likely be doing it over and over again (boring!). With testing this becomes a 2 second cognition-free process, and even that can be automated with Grunt/gnotify notifications. The boring part of coding is now automated. With good coupling, you can quickly isolate your change/compile/run cycle to the part of the code you're working on. Programmers already know the benefits that testing brings 6 months down the line when something breaks, but it's wishful thinking to expect people to think that far ahead (and smaller companies are often in a hurry to get something out the door before the money dries up). If you want intrinsic motivation to write tests, you learn how to work such that tests provide immediate benefit.