{"id":12181,"date":"2016-03-03T11:01:15","date_gmt":"2016-03-03T09:01:15","guid":{"rendered":"https:\/\/mozaicworks.com\/?p=8929"},"modified":"2023-09-15T14:57:39","modified_gmt":"2023-09-15T11:57:39","slug":"software-craftsmans-tools-unit-testing","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/software-craftsmans-tools-unit-testing","title":{"rendered":"Software Crafer&#8217;s Tools: Unit Testing"},"content":{"rendered":"\n<p><em>This article was first published&nbsp;in&nbsp;<a href=\"http:\/\/www.todaysoftmag.com\/article\/422\/software-craftsman-s-tools-unit-testing\">Today Software Magazine, no&nbsp;12<\/a>. Below it\u2019s the full&nbsp;version.&nbsp;<\/em><em>The authors are:&nbsp;<em><a href=\"\/trainer\/alex-bolboaca\">Alexandru Bolboaca<\/a>&nbsp;and&nbsp;<a href=\"https:\/\/mozaicworks.com\/trainers-coaches\/adrian-bolboaca\/\">Adrian Bolboaca.<\/a><\/em><\/em><\/p>\n\n\n\n<p><strong>The Problem<\/strong><\/p>\n\n\n\n<p>Imagine the following situation: a team has developed for 6 months a great product that immediately sells. Users show their passion for the product by asking new features. If the team does not deliver the new features fast enough, their happiness will decrease. They might even switch to a competing application. The team must deliver quickly.<\/p>\n\n\n\n<p>Unfortunately, it takes weeks or months to validate the product completely, without accounting the time for bug-fixing. The team cannot deliver in time if the product is tested completely. What can they do?<\/p>\n\n\n\n<p>The most common strategies are:<\/p>\n\n\n\n<ul>\n<li>test only new features, hoping that the old ones have not modified<\/li>\n\n\n\n<li>analyze the impact of changes and test only the affected features<\/li>\n\n\n\n<li>users test the application during a stabilization period.<\/li>\n<\/ul>\n\n\n\n<p>All these strategies translate into temporarily decreasing the care for the product in order to obtain faster delivery. Unfortunately, the technical teams in the scenarios above are taking business risks. Their major risk is missing the impact on certain application areas and delivering bugs. This can turn into:<\/p>\n\n\n\n<ul>\n<li>Decreased user happiness and creating detractors. In business and life winning a person&#8217;s trust is hard, but very easy to loose.<\/li>\n\n\n\n<li>Increased support cost. Every bug reported by users means time spent to understand, solve, test and deploy of the new version. Expenses accumulate in: call center, development, testing, operational etc.<\/li>\n\n\n\n<li>Opportunity cost: while the team solves bugs, the competition can produce new features that get the users. Solving bugs is equivalent from the business point of view with running in place.<\/li>\n<\/ul>\n\n\n\n<p><b><i>What if&#8230;&nbsp;<\/i><\/b><\/p>\n\n\n\n<p>The team could validate the whole application in hours and not in weeks or months?<\/p>\n\n\n\n<p>What if each programmer could learn after each code change, in minutes, that nothing else was affected (with 80+% probability)?<\/p>\n\n\n\n<p>The article on Software Craft mentions the main idea of the movement: a software crafter can deliver quality under pressure. Given the circumstances above, a software crafter should deliver new features in the given time with as few bugs as possible. How few? Less than 10 per release. This is a conservative number. Agile methods (including Scrum) demand 0 known bugs at the end of each 2-3 weeks sprint, after a validation by testers.<\/p>\n\n\n\n<p><b><i>But any software application has bugs!&nbsp;<\/i><\/b><\/p>\n\n\n\n<p>The name \u201cbug\u201d is a euphemism for mistake. Mistakes are normal in any human activity, including software development.<\/p>\n\n\n\n<p>How can we reduce the mistakes and their impact? Unit testing is a tool that can help, but it is not the only one. Others are: code review, pair programming, reducing the number of lines of code, design by contract.<\/p>\n\n\n\n<p><b><i>Unit testing&nbsp;<\/i><\/b><\/p>\n\n\n\n<p>Unit testing means writing code, named testing code, that validates the production code. Testing most of the application becomes automatic.<\/p>\n\n\n\n<p>History: programmers often believe that unit testing is a new practice. The reality is that unit testing was used from the times of mainframe computers and punch cards. Back then, debugging was very difficult because it implied reading tens of meters of sheets of paper printed with the program results and execution information. Automated tests that ran at the same time as the program gave much more information about the source of the mistakes.<\/p>\n\n\n\n<p>What about testers? They are often afraid that they&#8217;ll lose their work once automated testing is introduced. The truth is that testers become much more important because they&#8217;re the only ones who can discover hidden problems, difficult or impossible to find with automated tests. They help increase the probability of correctness from 80+% to almost 100%.<\/p>\n\n\n\n<p>Unit tests have a few important properties:<\/p>\n\n\n\n<ul>\n<li>each test validates one small behavior of the application<\/li>\n\n\n\n<li>run really fast, under a few minutes<\/li>\n\n\n\n<li>are short and easy to read<\/li>\n\n\n\n<li>run on the push of a button, without additional configurations<\/li>\n<\/ul>\n\n\n\n<p>To be fast, unit tests often use so called \u201ctest doubles\u201d. Similar with plane pilots that learn in a simulator before driving a plane, unit tests use pieces of code that look like the production code but are only used for testing. Stubs and mocks are the most common test doubles; others exist but are less used.<\/p>\n\n\n\n<p>A stub is a test double that returns values. A stub is similar with a very simple simulation: when a button is pressed, a value appears. A manually written stub looks like this:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><a href=\"https:\/\/mozaicworks.com\/wp-content\/uploads\/2016\/03\/Screen-Shot-2016-04-20-at-1.09.45-PM.png\" rel=\"attachment wp-att-9326\" class=\"broken_link\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-9326 size-full\" src=\"https:\/\/mozaicworks.com\/wp-content\/uploads\/2016\/03\/Screen-Shot-2016-04-20-at-1.09.45-PM.png\" alt=\"Screen Shot 2016-04-20 at 1.09.45 PM\" width=\"675\" height=\"319\"><\/a><\/pre>\n\n\n\n<p>A mock is a test double that validates collaboration between objects. Mocks validate method calls with certain parameters, for a certain number of times. A mock can be used to validate method calls for methods that don&#8217;t return values.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><a href=\"https:\/\/mozaicworks.com\/wp-content\/uploads\/2016\/03\/Screen-Shot-2016-04-20-at-1.19.04-PM.png\" rel=\"attachment wp-att-9327\" class=\"broken_link\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-9327 size-full\" src=\"https:\/\/mozaicworks.com\/wp-content\/uploads\/2016\/03\/Screen-Shot-2016-04-20-at-1.19.04-PM.png\" alt=\"Screen Shot 2016-04-20 at 1.19.04 PM\" width=\"721\" height=\"434\"><\/a>\n<\/pre>\n\n\n\n<p>Test doubles can be created using special frameworks, like mockito for Java (ports exist for other languages) or moq for .NET.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><a href=\"https:\/\/mozaicworks.com\/wp-content\/uploads\/2016\/03\/Screen-Shot-2016-04-20-at-1.20.19-PM.png\" rel=\"attachment wp-att-9328\" class=\"broken_link\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-9328 size-full\" src=\"https:\/\/mozaicworks.com\/wp-content\/uploads\/2016\/03\/Screen-Shot-2016-04-20-at-1.20.19-PM.png\" alt=\"Screen Shot 2016-04-20 at 1.20.19 PM\" width=\"715\" height=\"357\"><\/a><\/pre>\n\n\n\n<p>Test doubles were initially used only in places where controlling the system was very hard or where tests were slow due to calls to external systems. In time, test doubles became more used in all unit tests, resulting in the \u201cmockist\u201d way of testing. The article <a href=\"http:\/\/martinfowler.com\/articles\/mocksArentStubs.html\">Mocks aren&#8217;t stubs<\/a> by Martin Fowler has much more details.<\/p>\n\n\n\n<p>Unit tests are written by a programmer, during the implementation of a feature.<\/p>\n\n\n\n<p>Unfortunately, the most common way of writing tests is sometime after the implementation was finished. The usual result is that the tests are not written or they are written based on the existing implementation and not on the correct application behavior.<\/p>\n\n\n\n<p>Test First Programming is a way to write tests that has the following steps:<\/p>\n\n\n\n<ul>\n<li>design the solution<\/li>\n\n\n\n<li>write the minimum code (compilable, if the programming language is compiled) based on the design<\/li>\n\n\n\n<li>write one or more tests that show what the implementation should do; the tests will fail<\/li>\n\n\n\n<li>write the code to make tests pass.<\/li>\n<\/ul>\n\n\n\n<p>By applying Test First Programming, the developers make sure that they write unit tests and they test the required behavior.<\/p>\n\n\n\n<p><a href=\"https:\/\/mozaicworks.com\/blog\/test-driven-development-incremental-design\/\">Test Driven Development (TDD)<\/a> can be considered a third way of writing tests.<\/p>\n\n\n\n<p>Actually, TDD is a way of making incremental design.<\/p>\n\n\n\n<p><b><i>Writing tests takes a long time!&nbsp;<\/i><\/b><\/p>\n\n\n\n<p>Case studies &nbsp;and personal experiences show that the time spent just to develop a feature is indeed increasing when adopting unit testing. Same studies show the time spent to maintain the product decreases considerably, showing that unit testing can be a net optimization in the total development time.<\/p>\n\n\n\n<p>However, no study can change the programmer&#8217;s feeling that he or she writes more code. Often, programmers assume that the project is slower because of automated testing.<\/p>\n\n\n\n<p><b><i>How do I start?&nbsp;<\/i><\/b><\/p>\n\n\n\n<p>The best way to adopt unit testing is carefully and incrementally, following a few important points:<\/p>\n\n\n\n<p><b>Option 1<\/b>.<b>&nbsp;<\/b>Clarify unit testing concepts<\/p>\n\n\n\n<p>Programmers should handle fearlessly concepts like: stubs, mocks, state tests, collaboration tests, contract tests, dependency injection etc. Programmers should also understand what cases are worth testing.<\/p>\n\n\n\n<p>Mastering this concept is possible in a few ways:<\/p>\n\n\n\n<ul>\n<li>specialized unit testing workshops (<a href=\"https:\/\/mozaicworks.com\">Mozaic Works<\/a> offers such a <a href=\"https:\/\/mozaicworks.com\/public-trainings-and-workshops\/unit-testing-workshop-v2-0\/\">workshop<\/a> that constantly had feedback over 9.25\/10 from the attendees)<\/li>\n\n\n\n<li>pair programming between a tester and a programmer<\/li>\n\n\n\n<li>pair programming between an experienced unit tester and a beginner. The experienced unit tester can be an external technical coach<\/li>\n\n\n\n<li>reading books (see the recommended books at the end), Internet resources or attending community events<\/li>\n\n\n\n<li>attending conferences where concepts related to unit testing are discussed<\/li>\n<\/ul>\n\n\n\n<p><b>Option 2. <\/b>A technical coach or trainer can work with programmers, helping them transfer theoretical information in their everyday practice such that productivity is least affected<\/p>\n\n\n\n<p><b>Option 3. <\/b>Write unit tests for the most important parts of the application and then of the features with the highest risk of mistake<\/p>\n\n\n\n<p><b>Option 4. <\/b>Use the \u201cTest pyramid\u201d testing strategy to eliminate as many mistakes as possible<\/p>\n\n\n\n<p><b>Option 5. <\/b>If lots of code without tests exists (legacy code), learning additional techniques to write tests on existing code is recommended. More details in a future article.<\/p>\n\n\n\n<p><b><i>Common mistakes&nbsp;<\/i><\/b><\/p>\n\n\n\n<p>A few common mistakes related to unit testing are:<\/p>\n\n\n\n<ul>\n<li>&nbsp;Writing too many integration tests3 (that exercise more classes and modules) that are slow and fragile instead of unit tests that are small, fast, easy to maintain<\/li>\n\n\n\n<li>Not using test doubles, or using them for other purposes than they were created for. Test doubles help writing short, fast tests.<\/li>\n\n\n\n<li>The test names don&#8217;t express the tested behavior. The test name can provide a lot of information when the test fails.<\/li>\n\n\n\n<li>Extensive usage of debuggers when tests fail. Well written tests immediately tell where the problem is when they fail. Debugging is still useful in exotic situations.<\/li>\n\n\n\n<li>Not caring for the testing code. The test code is at least as important as the production code.<\/li>\n<\/ul>\n\n\n\n<p><b><i>Conclusion&nbsp;<\/i><\/b><\/p>\n\n\n\n<p>Unit testing is one of the tools a programmer can use to significantly reduce the number of mistakes he or she makes when writing code. When correctly used, unit testing can significantly reduce the time spent with bug fixing, reducing the load on colleagues that take care of support and testing and allowing the introduction of new features faster, resulting in higher competitiveness.<\/p>\n\n\n\n<p>Care must be taken when adopting unit testing by following industry&nbsp;practices (<a href=\"https:\/\/watirmelon.com\/2012\/01\/31\/introducing-the-software-testing-ice-cream-cone\/\">the pyramid of tests<\/a>, using test doubles etc). External help (training and technical coaching) can make the difference between a successful and a challenged adoption. Technical coaching is a fast way of adopting a new practice, with hands-on, on the job and on production code help of a person specialized in the technique and in teaching it.<\/p>\n\n\n\n<p>A software crafter masters unit testing and uses it to protect from his or his colleagues&#8217; mistakes. He\/she is certain can deliver bug-free software even under time pressure. Of course, the condition is to know unit testing so well that it is the default way of work even when under pressure.<\/p>\n\n\n\n<p><i>Recommended books<\/i><\/p>\n\n\n\n<p><i>\u201eThe Art of Unit Testing\u201d, Roy Osherove<br>\u201exUnit Test Patterns\u201d, Gerard Meszaros<br>\u201eGrowing Object Oriented Software Guided by Tests\u201d, Steve Freeman, Nat Pryce&nbsp;<\/i><\/p>\n\n\n\n<p><i>Notes<\/i><i><br><\/i><\/p>\n\n\n\n<p><i>The most well known case study on unit testing took place at Microsoft. More details <a href=\"http:\/\/collaboration.csc.ncsu.edu\/laurie\/Papers\/Unit_testing_cameraReady.pdf\">here<\/a>.&nbsp;<\/i><\/p>\n\n\n\n<p>Photo source<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This article was first published&nbsp;in&nbsp;Today Software Magazine, no&nbsp;12. Below it\u2019s the full&nbsp;version.&nbsp;The authors are:&nbsp;Alexandru Bolboaca&nbsp;and&nbsp;Adrian Bolboaca. The Problem Imagine the following situation: a team has developed for 6 months a great product that immediately sells. Users show their passion for the product by asking new features. If the team does not deliver the new features [&hellip;]<\/p>\n","protected":false},"author":9,"featured_media":9315,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"footnotes":""},"categories":[1127,1103,1125,1126,1151],"tags":[1160,1153],"acf":[],"_links":{"self":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12181"}],"collection":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/comments?post=12181"}],"version-history":[{"count":2,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12181\/revisions"}],"predecessor-version":[{"id":15488,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12181\/revisions\/15488"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/media\/9315"}],"wp:attachment":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/media?parent=12181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/categories?post=12181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/tags?post=12181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}