{"id":126,"date":"2010-03-08T21:36:18","date_gmt":"2010-03-09T04:36:18","guid":{"rendered":"http:\/\/www.jusquici.org\/blog\/?p=126"},"modified":"2010-05-24T10:25:35","modified_gmt":"2010-05-24T17:25:35","slug":"tdd-the-war-on-errors","status":"publish","type":"post","link":"https:\/\/www.jusquici.org\/blog\/?p=126","title":{"rendered":"TDD: the war on errors"},"content":{"rendered":"

In the past two years, there has been an emphasis on Test Driven Development in Design Studio.<\/p>\n

There seems to be a misconception about the past, though: it’s sometimes spoken as if testing was not part of DS previously. This is untrue – no team fired up notepad, wrote some code, and turned it over. Instead, “testing” has come to mean “having a robust automated test suite.” That’s great, and it is amazing that so many more teams are building those suites now. But we also have to remember it isn’t the only part of how we should test software.<\/p>\n

Below is my first draft of a process-style diagram of how things “should be” in our process. It’s far too big to fit in here at 100% size, so click through to see it in all its glory. I’m looking for any thoughts or corrections to it before I make a final infographic-style rendition. <\/p>\n

\"\"<\/a><\/p>\n

A few things to note:<\/p>\n