And you are here why?

“I don’t see why I need to write tests for it — *I* wrote this, and it works.”  —  #CowboyDeveloper /via http://turnoff.us/geek/tdd-vs-ftt/ Categories of developers 1.  Can’t have enough tests : Vanishingly few, but so so useful when it comes to building out fault-tolerant systems 2.  Usually write tests, but occasionally skip ’em for the “Obvious Stuff” : Sadly, most of us 3.  Consider their (passing) tests proof that everything is golden : Annoying, and definitely the ones that will take your system down at an inopportune moment 4.  Write tests only when forced to do so : The worst of the lot, epitomized by the quote at the top of the post. Their development style can be best described as  FTT , for “ F**k The Tests ”.

“ Code is either growing or staling ”  —  Me /via https://www.monkeyuser.com/2017/unit-tests-coverage-degradation/ When we think of Legacy Code, we usually think of it as  a pejorative . If we’re a bit more enlightened, we might think of it as “ all the code you’ve written, all the frameworks from the past, all the processes that exist to deal with edge cases, and all the skills that you no longer use ” (•) Which is all well and good, except that one of the most important components of legacy code is all the tests embedded in it. Think about it this way — it’s really pretty hard to maintain test coverage on your  existing code, right? Now imagine doing this for one of the legacy systems. The sequence probably goes like this 1.  Somebody reports an issue 2.  You poke around in the code, half-remembering how stuff works, and eventually produce a fix 3.  OH NOES, some of the tests staled out due to the fix, others ‘cos data has changed, and that’s ...

/via http://turnoff.us/geek/the-depressed-developer-17/ Me, in my fantasies : “ The tests should cover what it *should* do, not what it does ” Me, in reality : “ Could we please get   some   unit tests in here? ”