{"id":2650,"date":"2021-08-31T14:24:39","date_gmt":"2021-08-31T18:24:39","guid":{"rendered":"https:\/\/blogs.mathworks.com\/developer\/?p=2650"},"modified":"2022-11-03T11:03:08","modified_gmt":"2022-11-03T15:03:08","slug":"why-testing-is-worth-the-effort","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/developer\/2021\/08\/31\/why-testing-is-worth-the-effort\/","title":{"rendered":"Do you feel lucky, punk?"},"content":{"rendered":"<div class=\"content\"><!--introduction-->\r\n<p>I'm part of the MathWorks <a href=\"https:\/\/www.mathworks.com\/services\/consulting.html\">consulting team<\/a> based in the UK specialising in software architecture and testing (Andy's <a href=\"https:\/\/blogs.mathworks.com\/developer\/2020\/11\/13\/all-your-database-are-belong-to-us\/\">posted an article from me<\/a> before). As part of some recent training I was delivering, I was contemplating this diagram that has been floating around internally for a number of years:<\/p>\r\n\r\n<p style=\"text-align: center\"><img decoding=\"async\" vspace=\"5\" hspace=\"5\" src=\"https:\/\/blogs.mathworks.com\/developer\/files\/y2021_doINeedATest.png\" alt=\"\"> <\/p>\r\n\r\n<p>Hilarious, I know. The point being made is an obvious one, which got me thinking &#8211; if it&#8217;s so obvious that writing tests is a good idea, why don&#8217;t more people do it?<\/p>\r\n\r\n<p><b>You need a test, so why don't you write one?<\/b><\/p>\r\n\r\n<p>I came up with some possible reasons as to why people don&#8217;t write tests:<\/p>\r\n<!--\/introduction-->\r\n<div><ol>\r\n<li>They don't know how.<\/li>\r\n<li>They think it's difficult.<\/li>\r\n<li>They think that they don&#8217;t have the time.<\/li>\r\n<li>They haven't been bitten yet &#8211; maybe their code is not sufficiently large\/complex\/business-critical yet for a major outage to have occurred.<\/li>\r\n<\/ol><\/div>\r\n\r\n<p>For the last of those points, you&#8217;ve got to ask yourself one question: Do I feel lucky?<\/p>\r\n\r\n<p>Thinking of some of the customer projects I&#8217;ve worked on, people rely on the apps developed. If they stop working, they&#8217;re not going be putting lives at risk, but 10-100s of people might not be able to do their work. This costs time and money, and there might be reputational damage for the team that develops the app. I don&#8217;t feel lucky!<\/p>\r\n\r\n<p><b>Test automation takes the luck out of software delivery<\/b><\/p>\r\n\r\n<p>I think it&#8217;s widely accepted in the software industry that:<\/p>\r\n<div><ul>\r\n<li>Software is getting more complex.<\/li>\r\n<li>Our reliance on it is increasing.<\/li>\r\n<li>Development teams are getting bigger.<\/li>\r\n<li>Updates\/deliveries are required more often.<\/li>\r\n<\/ul><\/div>\r\n\r\n<p>We therefore need tests to:<\/p>\r\n<div><ul>\r\n<li>Validate that complex behaviour.<\/li>\r\n<li>Ensure robustness.<\/li>\r\n<li>Check code from the whole team works together when integrated.<\/li>\r\n<\/ul><\/div>\r\n\r\n<p>By running those tests quickly and efficiently through automation, we can achieve those frequent deliveries with confidence.<\/p><p><b>Testing helps individual developers too<\/b><\/p>\r\n\r\n<p>Here are five ways in which testing has helped me out on real projects:<\/p>\r\n<div><ol>\r\n<li>Testing has allowed me to <b>make changes to large projects with confidence<\/b>. I don't know exactly what the code does, even after a long time working on it. Sure, I can give an executive summary, or I can tell you the low-level details of the particular code I've worked on, but not everything in-between. That&#8217;s the domain knowledge of the customer&#8217;s engineers. By running the tests, I can be sure that everything still works.<\/li>\r\n<li>Tests have helped me to <b>learn a new code base<\/b> when I've been dropped into a project. They show me how the code is meant to be used and what the dependencies are.<\/li>\r\n<li>Tests <b>encapsulate the knowledge<\/b> I&#8217;ve gained and design decisions I&#8217;ve made as part of the development process, even on a very small project. I'm repeatedly amazed at how quickly complexity builds up &#8211; within a couple of hours of coding, I've lost track of what each piece of code is meant to do and all the edge cases it handles.<\/li>\r\n<li>Testing allows me to <b>focus on requirements rather than implementation<\/b> details. This is particularly useful when the implementation is not obvious. I can follow the process of identifying what it needs to do, writing a (failing) test to capture that information, doing some implementation, and then iterating &#8211; &#8220;<a href=\"https:\/\/blog.cleancoder.com\/uncle-bob\/2014\/12\/17\/TheCyclesOfTDD.html\">red, green, refactor<\/a>&#8221;.<\/li>\r\n<li>It helps <b>drive software architecture<\/b> through the creation of small, focussed, <i>testable<\/i> components. If the code is difficult to test, it&#8217;s almost certainly because I&#8217;ve designed it wrong.<\/li>\r\n<\/ol><\/div>\r\n\r\n<p><b>Testing is now standard practice<\/b><\/p><p>In mainstream software development, writing tests has been standard practice for 10+ years. The &#8220;punks&#8221; have gone &#8211; professional rigor and <a href=\"https:\/\/en.wikipedia.org\/wiki\/Software_craftsmanship\">craftsmanship<\/a> is required. Writing tests goes hand in hand with writing the code.<\/p><p>It has been said (I&#8217;ve forgotten who &#8211; maybe <a href=\"https:\/\/blog.cleancoder.com\/\">Uncle Bob<\/a>, maybe one of the many good talks from <a href=\"https:\/\/www.youtube.com\/user\/CppCon\">Cpp Con<\/a>) that if you were to ask people in the late 90s or early 2000s whether they use version control, you would have got a patchy response &#8211; it wasn&#8217;t common place. Today, if you're not using version control, you'd be mocked! How could you possible develop anything without version control? Testing is going through the same transition. Don&#8217;t be the butt of the joke!<\/p><p>Whether your team or customer is demanding tests, as a software industry professional, you should be showing them the way!<\/p><p><b>Start writing tests today<\/b><\/p><p>You should start writing tests whenever you start a project. Complexity builds up surprisingly quickly so start testing from the beginning. It&#8217;s much, much easier to write tests as you go rather than coming back later and trying to do it.<\/p><p>Failing that, start now! If you already have a project without tests, don&#8217;t be put off. You can adopt an incremental or &#8220;fix as you go&#8221; approach to build up your tests. Writing tests doesn&#8217;t need to be a monolithic undertaking. Over time your test suite and coverage will increase.<\/p><p>A common question related to this is how to manage the transition from prototyping algorithms and workflows to a more formal implementation with tests. The objection goes &#8220;what&#8217;s the point of writing all these tests when the code is in so much flux?&#8221;.<\/p><p>Here, a judgement call is required. In the first stage you&#8217;re answering questions like &#8220;is this even possible&#8221;, &#8220;how do I actually do it&#8221;, and &#8220;is the result worth further investment&#8221;. In the second stage, you start to rely on the answers the code produces, or maybe others will want to run your code too. Either way, you&#8217;re starting to build a tool.<\/p><p>As soon as there&#8217;s a hint of stage two, start testing!<\/p><p><b>&#8220;But I don&#8217;t have time for any of this&#8221;<\/b><\/p><p>This common objection has been covered in many testing books and articles. To cite <a href=\"https:\/\/en.wikipedia.org\/wiki\/Kent_Beck\">Kent Beck<\/a> as just one example:<\/p><p><i>&#8220;The more stress you feel, the less testing you will do. The less testing you do, the more errors you will make. The more errors you make, the more stress you feel. Rinse and repeat&#8221;.<\/i><\/p><p>--  Beck, K. (2003). <i>Test-Driven Development: By Example<\/i>. Boston: Addison-Wesley<\/p><p>Think of that bug that appears late in the development process and takes days to track down. What if you had an automated test that pinpointed it as soon as it appeared? Think of a worse scenario &#8211; you&#8217;ve already released your code when a bug is found. How much time will that take to fix? I can guarantee it won&#8217;t happen at 9 o&#8217;clock on a Monday morning. Try 5pm on a Friday!<\/p><p>Now imagine an alternative world &#8211; you need to ship a new feature to meet a tight deadline. You integrate the code but are worried that it could break something else. But you remember you&#8217;ve got a test suite with full coverage that you trust. You run the suite and everything passes. You ship the code fully confident that everything works and go home on time.<\/p><p>So ultimately, do you have time <i>not<\/i> to test?<\/p><p><b>So how do you get started with testing in MATLAB?<\/b><\/p><p>How to <i>do<\/i> testing is an entire topic in itself. For now, I&#8217;m just going to point you to some resources to help you get started:<\/p><div><ul><li>MATLAB comes with the <a href=\"https:\/\/www.mathworks.com\/help\/matlab\/class-based-unit-tests.html\">Unit Testing<\/a>, <a href=\"https:\/\/www.mathworks.com\/help\/matlab\/app-testing-framework.html\">App Testing<\/a>, <a href=\"https:\/\/www.mathworks.com\/help\/matlab\/performance-testing-framework.html\">Performance Testing<\/a> and <a href=\"https:\/\/www.mathworks.com\/help\/matlab\/mocking-framework.html\">Mocking Frameworks<\/a>.<\/li><li>There are lots more <a href=\"https:\/\/blogs.mathworks.com\/developer\/category\/testing\/?s_tid=Blog_developer_Category\">posts on this blog<\/a> about testing, including the <a href=\"https:\/\/blogs.mathworks.com\/developer\/2020\/11\/13\/all-your-database-are-belong-to-us\/\">Database Testing Framework<\/a> which I have written about previously.<\/li><li>You can talk to our amazing training team about <a href=\"http:\/\/www.mathworks.com\/learn\/training\/value-of-training.html\">courses on testing<\/a>.<\/li><li>Have a look at our <a href=\"https:\/\/blogs.mathworks.com\/developer\/2020\/12\/15\/cloud-ci-services\/\">continuous integration options<\/a> for running your tests automatically. There is support for Jenkins, Travis CI, GitHub Actions, Circle CI, and Azure Pipelines, as well as <a href=\"https:\/\/github.com\/mathworks\/matlab-bamboo-plugin\">Atlassian Bamboo<\/a>.<\/li><li>If you want to get more into the theory, try reading <a href=\"https:\/\/www.oreilly.com\/library\/view\/test-driven-development\/0321146530\/\">Test-Driven Development<\/a> by Kent Beck or <a href=\"https:\/\/www.oreilly.com\/library\/view\/growing-object-oriented-software\/9780321574442\/\">Growing Object-Oriented Software<\/a> by Freeman and Pryce.<\/li><\/ul><\/div><p><b>And finally...<\/b><\/p><p>Yes I know - the title is a misquote. The actual quote is <i>\"...you've got to ask yourself one question: 'Do I feel lucky?' Well, do you, punk?\"<\/i>.<\/p><script language=\"JavaScript\"> <!-- \r\n    function grabCode_97e3b5350c684eb99e58c0e3c24abe7b() {\r\n        \/\/ Remember the title so we can use it in the new page\r\n        title = document.title;\r\n\r\n        \/\/ Break up these strings so that their presence\r\n        \/\/ in the Javascript doesn't mess up the search for\r\n        \/\/ the MATLAB code.\r\n        t1='97e3b5350c684eb99e58c0e3c24abe7b ' + '##### ' + 'SOURCE BEGIN' + ' #####';\r\n        t2='##### ' + 'SOURCE END' + ' #####' + ' 97e3b5350c684eb99e58c0e3c24abe7b';\r\n    \r\n        b=document.getElementsByTagName('body')[0];\r\n        i1=b.innerHTML.indexOf(t1)+t1.length;\r\n        i2=b.innerHTML.indexOf(t2);\r\n \r\n        code_string = b.innerHTML.substring(i1, i2);\r\n        code_string = code_string.replace(\/REPLACE_WITH_DASH_DASH\/g,'--');\r\n\r\n        \/\/ Use \/x3C\/g instead of the less-than character to avoid errors \r\n        \/\/ in the XML parser.\r\n        \/\/ Use '\\x26#60;' instead of '<' so that the XML parser\r\n        \/\/ doesn't go ahead and substitute the less-than character. \r\n        code_string = code_string.replace(\/\\x3C\/g, '\\x26#60;');\r\n\r\n        copyright = 'Copyright 2021 The MathWorks, Inc.';\r\n\r\n        w = window.open();\r\n        d = w.document;\r\n        d.write('<pre>\\n');\r\n        d.write(code_string);\r\n\r\n        \/\/ Add copyright line at the bottom if specified.\r\n        if (copyright.length > 0) {\r\n            d.writeln('');\r\n            d.writeln('%%');\r\n            if (copyright.length > 0) {\r\n                d.writeln('% _' + copyright + '_');\r\n            }\r\n        }\r\n\r\n        d.write('<\/pre>\\n');\r\n\r\n        d.title = title + ' (MATLAB code)';\r\n        d.close();\r\n    }   \r\n     --> <\/script><p style=\"text-align: right; font-size: xx-small; font-weight:lighter;   font-style: italic; color: gray\"><br><a href=\"javascript:grabCode_97e3b5350c684eb99e58c0e3c24abe7b()\"><span style=\"font-size: x-small;        font-style: italic;\">Get \r\n      the MATLAB code <noscript>(requires JavaScript)<\/noscript><\/span><\/a><br><br>\r\n      Published with MATLAB&reg; R2021a<br><\/p><\/div><!--\r\n97e3b5350c684eb99e58c0e3c24abe7b ##### SOURCE BEGIN #####\r\n%% \r\n% I'm part of the MathWorks <https:\/\/www.mathworks.com\/services\/consulting.html \r\n% consulting team> based in the UK specialising in software architecture and testing \r\n% (Andy's <https:\/\/blogs.mathworks.com\/developer\/2020\/11\/13\/all-your-database-are-belong-to-us\/ \r\n% posted an article from me> before). As part of some recent training I was delivering, \r\n% I was contemplating this diagram that has been floating around internally for \r\n% a number of years:\r\n% \r\n% <<y2021_doINeedATest.png>> \r\n% \r\n% Hilarious, I know. The point being made is an obvious one, which got me thinking \r\n% \u2013 if it\u2019s so obvious that writing tests is a good idea, why don\u2019t more people \r\n% do it?\r\n% \r\n% \r\n% \r\n% *You need a test, so why don't you write one?*\r\n% \r\n% I came up with some possible reasons as to why people don\u2019t write tests:\r\n%% \r\n% # They don't know how.\r\n% # They think it's difficult.\r\n% # They think that they don\u2019t have the time.\r\n% # They haven't been bitten yet \u2013 maybe their code is not sufficiently large\/complex\/business-critical \r\n% yet for a major outage to have occurred.\r\n%% \r\n% For the last of those points, you\u2019ve got to ask yourself one question: Do \r\n% I feel lucky?\r\n% \r\n% Thinking of some of the customer projects I\u2019ve worked on, people rely on the \r\n% apps developed. If they stop working, they\u2019re not going be putting lives at \r\n% risk, but 10-100s of people might not be able to do their work. This costs time \r\n% and money, and there might be reputational damage for the team that develops \r\n% the app. I don\u2019t feel lucky!\r\n% \r\n% \r\n% \r\n% *Test automation takes the luck out of software delivery*\r\n% \r\n% I think it\u2019s widely accepted in the software industry that:\r\n%% \r\n% * Software is getting more complex.\r\n% * Our reliance on it is increasing.\r\n% * Development teams are getting bigger.\r\n% * Updates\/deliveries are required more often.\r\n%% \r\n% We therefore need tests to:\r\n%% \r\n% * Validate that complex behaviour.\r\n% * Ensure robustness.\r\n% * Check code from the whole team works together when integrated.\r\n%% \r\n% By running those tests quickly and efficiently through automation, we can \r\n% achieve those frequent deliveries with confidence.\r\n% \r\n% \r\n% \r\n% *Testing helps individual developers too*\r\n% \r\n% Here are five ways in which testing has helped me out on real projects:\r\n%% \r\n% # Testing has allowed me to *make changes to large projects with confidence*. \r\n% I don't know exactly what the code does, even after a long time working on it. \r\n% Sure, I can give an executive summary, or I can tell you the low-level details \r\n% of the particular code I've worked on, but not everything in-between. That\u2019s \r\n% the domain knowledge of the customer\u2019s engineers. By running the tests, I can \r\n% be sure that everything still works.\r\n% # Tests have helped me to *learn a new code base* when dropped into a project. \r\n% They show me how the code is meant to be used and what the dependencies are.\r\n% # Tests *encapsulate the knowledge* I\u2019ve gained and design decisions I\u2019ve \r\n% made as part of the development process, even on a very small project. I'm repeatedly \r\n% amazed at how quickly complexity builds up \u2013 within a couple of hours of coding, \r\n% I've lost track of what each piece of code is meant to do and all the edge cases \r\n% it handles.\r\n% # Testing allows me to *focus on requirements rather than implementation* \r\n% details. This is particularly useful when the implementation is not obvious. \r\n% I can follow the process of identifying what it needs to do, writing a (failing) \r\n% test to capture that information, doing some implementation, and then iterating \r\n% \u2013 \u201c<https:\/\/blog.cleancoder.com\/uncle-bob\/2014\/12\/17\/TheCyclesOfTDD.html red, \r\n% green, refactor>\u201d.\r\n% # It helps *drive software architecture* through the creation of small, focussed, \r\n% _testable_ components. If the code is difficult to test, it\u2019s almost certainly \r\n% because I\u2019ve designed it wrong.\r\n%% \r\n% \r\n% \r\n% *Testing is now standard practice*\r\n% \r\n% In mainstream software development, writing tests has been standard practice \r\n% for 10+ years. The \u201cpunks\u201d have gone \u2013 professional rigor and <https:\/\/en.wikipedia.org\/wiki\/Software_craftsmanship \r\n% craftsmanship> is required. Writing tests goes hand in hand with writing the \r\n% code.\r\n% \r\n% It has been said (I\u2019ve forgotten who \u2013 maybe <https:\/\/blog.cleancoder.com\/ \r\n% Uncle Bob>, maybe one of the many good talks from <https:\/\/www.youtube.com\/user\/CppCon \r\n% Cpp Con>) that if you were to ask people in the late 90s or early 2000s whether \r\n% they use version control, you would have got a patchy response \u2013 it wasn\u2019t common \r\n% place. Today, if you're not using version control, you'd be mocked! How could \r\n% you possible develop anything without version control? Testing is going through \r\n% the same transition. Don\u2019t be the butt of the joke!\r\n% \r\n% Whether your team or customer is demanding tests, as a software industry professional, \r\n% you should be showing them the way!\r\n% \r\n% \r\n% \r\n% *Start writing tests today*\r\n% \r\n% You should start writing tests whenever you start a project. Complexity builds \r\n% up surprisingly quickly so start testing from the beginning. It\u2019s much, much \r\n% easier to write tests as you go rather than coming back later and trying to \r\n% do it.\r\n% \r\n% Failing that, start now! If you already have a project without tests, don\u2019t \r\n% be put off. You can adopt an incremental or \u201cfix as you go\u201d approach to build \r\n% up your tests. Writing tests doesn\u2019t need to be a monolithic undertaking. Over \r\n% time your test suite and coverage will increase.\r\n% \r\n% A common question related to this is how to manage the transition from prototyping \r\n% algorithms and workflows to a more formal implementation with tests. The objection \r\n% goes \u201cwhat\u2019s the point of writing all these tests when the code is in so much \r\n% flux?\u201d.\r\n% \r\n% Here, a judgement call is required. In the first stage you\u2019re answering questions \r\n% like \u201cis this even possible\u201d, \u201chow do I actually do it\u201d, and \u201cis the result \r\n% worth further investment\u201d. In the second stage, you start to rely on the answers \r\n% the code produces, or maybe others will want to run your code too. Either way, \r\n% you\u2019re starting to build a tool.\r\n% \r\n% As soon as there\u2019s a hint of stage two, start testing!\r\n% \r\n% \r\n% \r\n% *\u201cBut I don\u2019t have time for any of this\u201d*\r\n% \r\n% This common objection has been covered in many testing books and articles. \r\n% To cite <https:\/\/en.wikipedia.org\/wiki\/Kent_Beck Kent Beck> as just one example:\r\n% \r\n% _\u201cThe more stress you feel, the less testing you will do. The less testing \r\n% you do, the more errors you will make. The more errors you make, the more stress \r\n% you feel. Rinse and repeat\u201d._\r\n% \r\n% REPLACE_WITH_DASH_DASH  Beck, K. (2003). _Test-Driven Development: By Example_. Boston: Addison-Wesley\r\n% \r\n% Think of that bug that appears late in the development process and takes days \r\n% to track down. What if you had an automated test that pinpointed it as soon \r\n% as it appeared? Think of a worse scenario \u2013 you\u2019ve already released your code \r\n% when a bug is found. How much time will that take to fix? I can guarantee it \r\n% won\u2019t happen at 9 o\u2019clock on a Monday morning. Try 5pm on a Friday!\r\n% \r\n% Now imagine an alternative world \u2013 you need to ship a new feature to meet \r\n% a tight deadline. You integrate the code but are worried that it could break \r\n% something else. But you remember you\u2019ve got a test suite with full coverage \r\n% that you trust. You run the suite and everything passes. You ship the code fully \r\n% confident that everything works and go home on time.\r\n% \r\n% So ultimately, do you have time _not_ to test?\r\n% \r\n% \r\n% \r\n% *So how do you get started with testing in MATLAB?*\r\n% \r\n% How to _do_ testing is an entire topic in itself. For now, I\u2019m just going \r\n% to point you to some resources to help you get started:\r\n%% \r\n% * MATLAB comes with the <https:\/\/www.mathworks.com\/help\/matlab\/class-based-unit-tests.html \r\n% Unit Testing>, <https:\/\/www.mathworks.com\/help\/matlab\/app-testing-framework.html \r\n% App Testing>, <https:\/\/www.mathworks.com\/help\/matlab\/performance-testing-framework.html \r\n% Performance Testing> and <https:\/\/www.mathworks.com\/help\/matlab\/mocking-framework.html \r\n% Mocking Frameworks>.\r\n% * There are lots more <https:\/\/blogs.mathworks.com\/developer\/category\/testing\/?s_tid=Blog_developer_Category \r\n% posts on this blog> about testing, including the <https:\/\/blogs.mathworks.com\/developer\/2020\/11\/13\/all-your-database-are-belong-to-us\/ \r\n% Database Testing Framework> which I have written about previously.\r\n% * You can talk to our amazing training team about <https:\/\/www.mathworks.com\/services\/training\/request_training.html \r\n% customised courses> on testing.\r\n% * Have a look at our <https:\/\/blogs.mathworks.com\/developer\/2020\/12\/15\/cloud-ci-services\/ \r\n% continuous integration options> for running your tests automatically. There \r\n% is support for Jenkins, Travis CI, GitHub Actions, Circle CI, and Azure Pipelines, \r\n% as well as <https:\/\/github.com\/mathworks\/matlab-bamboo-plugin Atlassian Bamboo>.\r\n% * If you want to get more into the theory, try reading <https:\/\/www.oreilly.com\/library\/view\/test-driven-development\/0321146530\/ \r\n% Test-Driven Development> by Kent Beck or <https:\/\/www.oreilly.com\/library\/view\/growing-object-oriented-software\/9780321574442\/ \r\n% Growing Object-Oriented Software> by Freeman and Pryce.\r\n%% \r\n% \r\n% \r\n% *And finally...*\r\n% \r\n% Yes I know - the title is a misquote. The actual quote is _\"...you've got \r\n% to ask yourself one question: 'Do I feel lucky?' Well, do you, punk?\"_.\r\n##### SOURCE END ##### 97e3b5350c684eb99e58c0e3c24abe7b\r\n-->","protected":false},"excerpt":{"rendered":"<div class=\"overview-image\"><img src=\"https:\/\/blogs.mathworks.com\/developer\/files\/y2021_doINeedATest.png\" class=\"img-responsive attachment-post-thumbnail size-post-thumbnail wp-post-image\" alt=\"Flowchart for whether you need a test\" decoding=\"async\" loading=\"lazy\" \/><\/div><!--introduction-->\r\n<p>I'm part of the MathWorks <a href=\"https:\/\/www.mathworks.com\/services\/consulting.html\">consulting team<\/a> based in the UK specialising in software architecture and testing (Andy's <a href=\"https:\/\/blogs.mathworks.com\/developer\/2020\/11\/13\/all-your-database-are-belong-to-us\/\">posted an article from me<\/a> before). As part of some recent training I was delivering, I was contemplating this diagram that has been floating around internally for a number of years:... <a class=\"read-more\" href=\"https:\/\/blogs.mathworks.com\/developer\/2021\/08\/31\/why-testing-is-worth-the-effort\/\">read more >><\/a><\/p>","protected":false},"author":178,"featured_media":2656,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[7],"tags":[],"_links":{"self":[{"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/posts\/2650"}],"collection":[{"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/users\/178"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/comments?post=2650"}],"version-history":[{"count":27,"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/posts\/2650\/revisions"}],"predecessor-version":[{"id":2940,"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/posts\/2650\/revisions\/2940"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/media\/2656"}],"wp:attachment":[{"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/media?parent=2650"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/categories?post=2650"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.mathworks.com\/developer\/wp-json\/wp\/v2\/tags?post=2650"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}