{"id":3342,"date":"2025-07-02T16:27:39","date_gmt":"2025-07-02T20:27:39","guid":{"rendered":"https:\/\/blogs.mathworks.com\/developer\/?p=3342"},"modified":"2025-07-02T16:27:39","modified_gmt":"2025-07-02T20:27:39","slug":"test-impact-analysis-intro","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/developer\/2025\/07\/02\/test-impact-analysis-intro\/","title":{"rendered":"TL;DR: Too Long; Didn’t Run"},"content":{"rendered":"

\r\nIn the fast-paced world of software development, speed<\/em> and quality<\/em> often feel like they're pulling us in opposite directions. On the one hand, we\u2019re racing to deliver new features and fixes. On the other, every change we make adds a little more complexity to the codebase \u2014 and with complexity comes risk. Bugs slip in. Dependencies tangle up. Suddenly, what once felt agile starts to feel... fragile. Finding the right balance between moving fast and maintaining reliable, high-quality software isn\u2019t easy. It\u2019s a real, everyday challenge for teams everywhere.\r\n<\/p>\r\n\r\n

One of the biggest hurdles?... Testing.<\/em><\/h2>\r\n

\r\n \r\n \"Testing\r\n <\/a>\r\nAs applications grow, so does the burden of making sure they still work after every small change. Running all<\/em> the tests every time you tweak a piece of code can be painfully inefficient. It drags down developer productivity, introduces bottlenecks in CI pipelines, and turns quick feedback loops into long, frustrating waits. \r\n<\/p>\r\n

Imagine fixing a minor issue in a single function \u2014 only to sit there while an entire suite of unrelated tests run. Not only is it a waste of time, but most of those tests may have nothing to do with the change you just made. It\u2019s easy to see how this adds up over time, leading to diminishing returns and growing developer frustration.\r\n<\/p>\r\n\r\n

\r\nWaste from running unrelated tests is not limited to development iterations. It slows down CI throughput. While it is a good practice to run all the tests at a meaningful cadence to ensure the entire application is always in a deployable state, running them all for every incremental job can be an overkill and hinders CI efficiency. It is counterproductive and makes an organization arguably less agile.\r\n<\/p>\r\n\r\n

We can be smarter. Let's see how!<\/h2>\r\n

\r\n \r\n \"Happy\r\n <\/a>\r\nR2025a<\/strong> release of MATLAB Test<\/strong> introduced a set of new features designed to ease some of these pain points \u2014 both during everyday development and when running automated builds locally or in CI. \r\n<\/p>\r\n\r\n

We'll dive into these capabilities in this blog series. I am planning a 4-part series at the moment, but we'll add more if we get carried away!\r\n<\/p>\r\n\r\nHere's what's coming:\r\n

\r\n