{"id":591,"date":"2016-10-06T09:44:34","date_gmt":"2016-10-06T13:44:34","guid":{"rendered":"https:\/\/george.hotelling.net\/91percent\/?p=591"},"modified":"2016-10-06T09:45:43","modified_gmt":"2016-10-06T13:45:43","slug":"testing-code-intentional-vs-incidental-behavior","status":"publish","type":"post","link":"https:\/\/george.hotelling.net\/91percent\/2016\/10\/06\/testing-code-intentional-vs-incidental-behavior\/","title":{"rendered":"Testing Code: Intentional vs. Incidental Behavior"},"content":{"rendered":"<p>Sometimes a maintenance programmer is <a href=\"https:\/\/blog.codinghorror.com\/coding-for-violent-psychopaths\/\">another developer with an axe<\/a>. Sometimes the maintenance programmer is ourselves after we have forgotten all about the project. I want whoever gets it to be happy and confident when they make changes.<\/p>\n<p>Having inherited projects in the past (both from others and from past-George), I think it&#8217;s important to make sure that a\u00a0project comes with good automated tests.<\/p>\n<p>Hopefully, in 2016 that isn&#8217;t a controversial statement. I do want to explicitly enumerate some of the value tests provide the maintenance programmer:<\/p>\n<ol>\n<li>Testing forces us to simplify and decouple our code, which makes maintaining a system easier. If it&#8217;s hard to test, it&#8217;s going to be hard to maintain.<\/li>\n<li>Tests provide example usage of the code, so they serve as living examples of how to use the code.<\/li>\n<li>Testing infrastructure. It&#8217;s easier to add one more test when they already have tests for other parts. It also provides examples to mimic when someone is getting up to speed.<\/li>\n<li>Good tests define what behavior is intentional.<\/li>\n<\/ol>\n<p>Let&#8217;s talk about #4.<\/p>\n<p>Virtually all code has\u00a0is intentional behavior and incidental behavior. Incidental behavior is what you get when a detail doesn&#8217;t matter to the functionality being developed. An example would be when your UI displays a list in whatever order the datasource provides it. You probably shouldn&#8217;t write a test for that; there&#8217;s no specified behavior.<\/p>\n<p>In a codebase with tests for the intentional behavior, a maintainer can be confident that any changes they make aren&#8217;t unknowingly undoing past decisions. The tests answer the question &#8220;is it supposed to be that way?&#8221;<\/p>\n<p>When retroactively adding tests (post-hoc testing) you run the risk of documenting the code instead of the requirements. If you find yourself writing tests with the goal of verifying the code works, you aren&#8217;t confirming that the code meets the requirements. You&#8217;re confirming that the code is the code.<\/p>\n<p>Should you find yourself writing post-hoc tests, what can you do? Try to put yourself in the shoes of the original author. Use <code>git blame<\/code> to discover\u00a0<em>why<\/em> the code was written. Write a test that verifies the original feature and no more.<\/p>\n<p>Finally, I suspect\u00a0that only testing intentional behavior is in conflict with 100% (or any) code coverage targets. If you have 100% coverage, either you are writing tests to cover code that isn&#8217;t part of the specification or you have a specification that is comprehensive to a fault.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Sometimes a maintenance programmer is another developer with an axe. Sometimes the maintenance programmer is ourselves after we have forgotten all about the project. I want whoever gets it to be happy and confident when they make changes. Having inherited projects in the past (both from others and from past-George), I think it&#8217;s important to &hellip; <a href=\"https:\/\/george.hotelling.net\/91percent\/2016\/10\/06\/testing-code-intentional-vs-incidental-behavior\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Testing Code: Intentional vs. Incidental Behavior<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":689,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[79],"class_list":["post-591","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming","tag-unit-testing"],"_links":{"self":[{"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/posts\/591","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/comments?post=591"}],"version-history":[{"count":10,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/posts\/591\/revisions"}],"predecessor-version":[{"id":691,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/posts\/591\/revisions\/691"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/media\/689"}],"wp:attachment":[{"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/media?parent=591"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/categories?post=591"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/tags?post=591"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}