{"id":1106,"date":"2005-09-23T14:16:33","date_gmt":"2005-09-23T18:16:33","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/2005\/09\/23\/unit-testing\/"},"modified":"2005-09-23T14:37:02","modified_gmt":"2005-09-23T18:37:02","slug":"unit-testing","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2005\/09\/23\/unit-testing\/","title":{"rendered":"Unit Testing"},"content":{"rendered":"

\r\n\r\nWil Shipley<\/a>’s heart is in the right place. It’s obvious that he\r\ncares about quality, and his experience and common sense rightly make\r\nhim skeptical of process. But I think he’s absolutely wrong about unit\r\ntesting. In brief, I think he misunderstands what unit testing is (or\r\nshould be) and what it’s useful for. He shoots down a stupid way of\r\ndoing testing, throws the baby out with the bathwater, and concludes\r\nthat it’s better to write good code in the first place, do manual\r\ntesting (“Try odd things. Whack keys.”), and rely on beta testers.\r\n<\/p>\r\n\r\n

\r\nI don’t deny that this approach has worked for him. He’s written\r\na lot of code, people have generally been happy with the products,\r\nand they’re not known for being buggy. But my hunch is that Wil’s\r\nteams have gotten good results because they’re unusually smart,\r\nexperienced, and hard-working. They’ve succeeded in spite of their\r\ntesting philosophy. Wil makes a great case that manual testing\r\nand defensive programming are necessary, but I think most\r\nprogrammers would be more effective and efficient if they combined\r\nthese with extensive automated unit testing.\r\n<\/p>\r\n\r\n

\r\nNow, I’ll be the first to say that by-the-book XP\/TDD goes overboard.\r\nIf you need a new class or method, I think it’s a waste of time to\r\nwrite a test that simply checks for the existence of the class or\r\nmethod, then write a stub, then run the tests, and then then flip back\r\nand write the real<\/em> tests. Perhaps that example is just for\r\npedagogical purposes and one isn’t meant to do that in production code.\r\n<\/p>\r\n\r\n

\r\nI also think it’s a waste of time to write tests for\r\neverything<\/em>. Some parts of the code are so simple that they\r\ndon’t need tests, though this applies less often than you might\r\nthink. Other times, it would take so much work to write a proper\r\ntest that it’s better to punt and check that item manually. (I’m\r\nthinking of user interface details that you’d immediately notice\r\nwhen running the application, as well as more elaborate\r\nsituations\/interactions. In the latter case, write the test down in\r\nEnglish and make sure that you really do it manually before\r\nshipping.) Again, though, this applies less often than you might\r\nthink.\r\n<\/p>\r\n\r\n

\r\nMy overall point is that time is limited, so you should use it wisely. And this\r\nis why extensive unit testing is a big win. Yes, it’s not possible for\r\nyour tests to cover all the pathways through the code, with all the\r\npossible inputs. And even if they could, it probably wouldn’t be a good\r\nidea to spend your time writing tests to do that. This does\r\nnot<\/em> mean, however, that you should reject unit testing as\r\nimpractical and try to test everything manually. That’s not a good use\r\nof time, either. In brief, proper unit testing saves time and improves\r\nquality because:\r\n<\/p>\r\n\r\n