{"id":37336,"date":"2020-05-19T16:37:39","date_gmt":"2020-05-19T14:37:39","guid":{"rendered":"http:\/\/arcadsoftware.com\/?p=37336"},"modified":"2026-03-18T10:56:43","modified_gmt":"2026-03-18T08:56:43","slug":"unit-testing-beating-technical-debt","status":"publish","type":"post","link":"https:\/\/www.arcadsoftware.com\/arcad\/news-events\/blog\/unit-testing-beating-technical-debt\/","title":{"rendered":"Unit Testing: Beating technical debt"},"content":{"rendered":"

By Olenka Van Schendel <\/h3>\n<\/div><\/div><\/div>

On modern, distributed systems, unit testing is arguably the most effective element of your testing strategy.\u00a0 A battery of well-designed unit tests “forces” the quality of your application as it is being developed<\/em> – and ideally even before.\u00a0 Unit test assets are then re-used continuously right across the lifetime of the application to catch any regressions in the system.<\/p>\n

Yet how can unit testing benefit legacy applications on IBM i \u2013 and especially those that were not designed with “units” in mind, and where monolithic code has been the norm?<\/p>\n

In this article we will examine the importance of unit testing in general and assess how relevant the technique is on IBM i.<\/p>\n<\/div>

Summary<\/h2>\n
    \n
  1. Quality from Quantity<\/a><\/li>\n
  2. Classification of defects<\/span><\/span><\/a><\/span><\/li>\n
  3. Shift Left \u2013 fail early<\/a><\/li>\n
  4. Clean, atomic code<\/a><\/li>\n
  5. What about the IBM i?<\/span><\/span><\/a><\/li>\n
  6. The importance of test automation on IBM i<\/a><\/span><\/span>\u00a0<\/span><\/li>\n
  7. Ensuring developer adoption of Unit Testing<\/a><\/span><\/span><\/li>\n<\/ol>\n<\/div>
    <\/div>\n

    1. Quality from Quantity<\/span><\/span>\u00a0<\/span><\/span>\u00a0<\/span><\/strong><\/h2>\n

    \"\"<\/p>\n

    Unit testing is often disregarded in favour of more “business-facing” techniques like functional or end-to-end testing.\u00a0 Unit testing takes up valuable developer time and especially so on a legacy code base like IBM i not overly structured in “units”.\u00a0 So how can a “white box” unit test, with no knowledge of the actual functionality of the application, safeguard the quality and accuracy of your system, let alone drive down your develoment costs as well?<\/p>\n

    The key is in the quantity<\/em> and the coverage<\/em> of the tests.<\/p>\n

    Unit testing involves creating a multitude of small, very simple test cases.\u00a0 Each test isolates a particular section of code (such as procedure, subroutine, conditional block), defining success or failure in terms of the expected output parameter values for a given input. \u00a0The test run is then stored as the “base line”, and subsequent tests are evaluated against this result.\u00a0 This makes unit tests very effective for detecting regressions in the system.\u00a0 They can be reused, grouped and executed as part of a suite at any time, such as after every system build, after an environment change, or before a particular component is transferred to QA.\u00a0 Unit tests created early on in the development phase can be used later to “smoke test” an application, to catch basic errors before any further time is wasted on more sophisticated testing.<\/p>\n

    <\/div>\n

    2. Classification of defects<\/strong><\/h2>\n

    Indeed, typical defect classifications reveal that software defects can be attributed to a wide variety of causes, including:<\/p>\n