{"id":455,"date":"2020-03-03T02:52:17","date_gmt":"2020-03-03T02:52:17","guid":{"rendered":"http:\/\/freedville.com\/blog\/?p=455"},"modified":"2020-03-03T02:52:17","modified_gmt":"2020-03-03T02:52:17","slug":"cognitive-system-testing-so-i-dont-need-to-unit-test-my-cognitive-system","status":"publish","type":"post","link":"https:\/\/freedville.com\/blog\/2020\/03\/03\/cognitive-system-testing-so-i-dont-need-to-unit-test-my-cognitive-system\/","title":{"rendered":"Cognitive System Testing: So, I don\u2019t need to unit test my cognitive system?"},"content":{"rendered":"\n

Part 6 of the\u00a0Cognitive System Testing<\/strong>\u00a0<\/a>series, originally posted in 2016 on IBM Developer<\/a>. <\/p>\n\n\n\n

Introduction<\/h2>\n\n\n\n

The last several blog chapters in this series focused on testing at the system and functional layers. You may be wondering if that means that as a cognitive system builder you don\u2019t need to worry about testing at the unit layer. Of course you do! Unit testing is still the foundation of testing a cognitive system and is critical for verifying that each of the system components is working correctly. The simple fact of the matter is that building good unit tests for a cognitive system is not that different from building unit tests for any other kind of software system.<\/p>\n\n\n\n

Building your system to support unit testing<\/h2>\n\n\n\n

\nThe most useful unit testing factor when writing code is to simply\nthink about how you could test each class\/unit that you are writing.\nBy simply writing classes with high cohesion and loose coupling, you\nare 90% of the way there. A cognitive system will involve many moving\nparts and several potential dependencies. Take care to provide ways\nto test your classes with minimal dependencies. For instance, very\nfew classes should require a database for testing. Instead use a data\naccess object pattern and dependency injection so that your class can\nbe tested with or without a database.<\/p>\n\n\n\n

Useful\npatterns in unit testing cognitive systems<\/strong><\/h2>\n\n\n\n

\nMost software developers are familiar with Design\nPatterns<\/a>, a set of useful blueprints for designing\ngood classes. I don\u2019t mean to suggest you write (or rewrite) your\ncode to use all of the Design Patterns, but there are several that\nhave proven very useful in my testing:<\/p>\n\n\n\n

\nFacade<\/a> \u2013\nfor abstracting away remote systems including databases and web APIs<\/p>\n\n\n\n

\nBridge<\/a> \u2013\nfor writing minimalist classes inside a framework (Servlet API, UIMA)\nwhile delegating most of the work to a second class (the bridge) that\ncan be tested independently of the first framework.   This\nlets me test most of a servlet implementation without a web\ncontainer, for instance.<\/p>\n\n\n\n

\nMediator<\/a> \u2013\nI like to write classes that don\u2019t know much about the world around\nthem, only interacting with dependencies via dependency injection.\nThen I use orchestrators to link these classes together and I test\nthe orchestrators with a mocking framework.<\/p>\n\n\n\n

\nFor more examples on this topic, I recommend the highly useful\nbook Practical\nUnit Testing with JUnit and Mockito<\/a> by Tomek\nKaczanowski<\/p>\n\n\n\n

Useful\nframeworks in unit testing<\/strong><\/h2>\n\n\n\n

\nEveryone has their own favorite frameworks, I don\u2019t mean to suggest\nthat these frameworks are the only ones you should consider, only\nthat it is important to have frameworks that help with at least these\naspects.<\/p>\n\n\n\n

\nMocking: If you are abstracting away your dependencies, you need a\nmocking framework capable of providing at least a \u2018stubbed\u2019\nversion of the dependency. Most mocking frameworks will let you\nspecify the behavior your mock should have and tell you which mocked\nmethods were called. My favorite mocking framework is Mockito<\/a>.<\/p>\n\n\n\n

\nParameterized testing: It\u2019s often useful to have the same test\nexecuted several times with different sets of inputs. I sometimes\nprefer to write my tests with \u2018test utility\u2019 methods, which seems\nto work better with some tooling, but when I want to separate the\ntest data from the test code I used JUnit\u2019s parameterized tests\ncapability.<\/p>\n\n\n\n

\nWeb service helpers: Rather than writing lots of boilerplate to call\nweb services and JSON parsers to verify responses, I use REST\nAssured<\/a>.<\/p>\n\n\n\n

What\nlevel of code coverage should I have in my unit tests?<\/strong><\/h2>\n\n\n\n

\nThis is a question that seems as contentious as vi vs emacs and where\nto put your curly braces. I am not a 100% code coverage zealot. There\nis only so much time to write code and write tests and thus you\nshould write as many tests as you need. A specific code coverage\ntarget invites the writing of bad tests simply to ensure code\ncoverage. Instead of coverage focus on test quality \u2013 are you\nwriting the tests you need and are they covering the most important\naspects of your application? Finally, if you focus on writing\nhigh-cohesion\/loosely-coupled classes that you could write unit tests\nfor, that pays hefty dividends towards a high quality system \u2013 and\nbuilding high quality systems is why I talk so much about testing in\nthe first place.<\/p>\n\n\n\n

Conclusion<\/strong><\/h2>\n\n\n\n

Despite this blog series\u2019 relative focus on system and functional testing, unit testing still provides the foundation for testing a cognitive system. The system should be built of high-cohesion\/loosely-coupled classes that are easily tested. Make use of appropriate design patterns and unit testing frameworks to increase the ease of writing tests. Don\u2019t aim for a specific code coverage target, aim for writing testable classes and high quality systems.<\/p>\n","protected":false},"excerpt":{"rendered":"

Part 6 of the\u00a0Cognitive System Testing\u00a0series, originally posted in 2016 on IBM Developer. Introduction The last several blog chapters in this series focused on testing at the system and functional layers. You may be wondering…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts\/455"}],"collection":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/comments?post=455"}],"version-history":[{"count":2,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts\/455\/revisions"}],"predecessor-version":[{"id":457,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts\/455\/revisions\/457"}],"wp:attachment":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/media?parent=455"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/categories?post=455"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/tags?post=455"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}