I work mainly with front-end JavaScript developers, who generally speaking got into programming through HTML and CSS and see testing as something someone else d

I work mainly with front-end JavaScript developers, who generally speaking got into programming through HTML and CSS and see testing as something someone else does after they've built the thing. (Which also perfectly describes me up until a year ago.) I don't have a reference for start-to-finish automated testing, but I like the way in which Justin Searles explains the difficulty of such a thing here: http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html http://blog.testdouble.com/posts/2014-01-25-the-failures-of-... I gave a brief presentation about testing a few months ago and felt like it didn't really connect. I think it's genuinely hard to break the preconceptions about testing, and also there's a fair amount of incidental framework and library minutia that can be hard to isolate from the big picture ideas. Subjective experience is a huge factor. Trying to rationally explain the advantages or conceptual underpinnings of testing doesn't always work. (In hindsight it didn't work for me either.) It really takes sitting down next to somebody and walking them through a process. I've had success in showing a test I wrote from some unit that I wanted to exist, deleting the implementation, walking them through a re-implementation, and then passing them the keyboard to implement another deleted implementation. Make sure that the developers actually experience a cycle of red-green-refactor.