The underlying logic behind the idea of shift left is that if errors or regressions are found sooner, fixing them will be quicker, easier and less expensive, and they’ll be less likely to end up leaking into production systems (whether accidentally or as an acceptable compromise).
Unit tests are the most foundational form of software testing, so they could be seen as the ultimate expression of shifting left. They’re a vital part of modern software development because they’re the fastest way to give precise, highly-targeted feedback to developers on the behavior of the code they’ve written (and any potential negative or unexpected consequences).
That means amongst many other jobs, developers are now part tester – they’re not just responsible for writing functional code, but also for writing and maintaining unit tests. For Java devs this usually takes up at least 20% of their working week, and often much more – a significant chunk of time that could otherwise be spent writing functional code customers will actually use!
But QA teams already employ a huge range of different functional test automation tools, so can’t we just use those to automate unit testing and give those developers a day (or more) of their valuable time back?
In short, no. Complete unit test automation and automated software testing are not the same. In this article we’ll take a brief look at why.
Automated functional testing
In traditional software development a QA team performs a range of testing once development is – at least theoretically – complete, to check that an application change works as expected and has not introduced any issues or regressions.
A number of different types of testing may be involved, depending on the application – including integration, end-to-end, acceptance, performance, regression and smoke testing. Other specific areas like security, accessibility and compatibility tests might also be part of the process. There’s a natural overlap between many of these activities, but all can be defined differently.
Effective functional testing is a vital part of keeping critical applications running and ensuring your customers want to use them, but doing it well takes significant effort. The tests involved are often complex, slow and hard to execute without specific subject matter expertise (how a business process is supposed to flow, for example, or how an interface should work). They also come with a number of related challenges, notably including test data preparation and management, and management of the tests themselves.
That’s why an entire category of software test automation tools has grown up over recent years, allowing QA teams to work more effectively, get more testing done and ensure greater software quality. Let’s take a very quick look at some well-known examples to illustrate the point:
Selenium – One of the most well-known UI testing tools, Selenium is an open source project that automates browser interactions to simulate user behavior.
Tricentis – Offers a range of test automation and management tools, including dedicated functional and mobile testing solutions. Strong focus on testing packaged Enterprise applications like SAP.
Sauce Labs – A web and mobile app testing platform built on Selenium, largely for UI and API testing.
Micro Focus – Has capabilities for test automation, test management, test lab/device management, test data and performance testing in a portfolio built largely around the venerable Unified Functional Testing tool (UFT).
Katalon – Offers a platform for UI and API test automation, test management, distributed testing in the cloud and AI-driven visual testing.
mabl – A low code test automation tool for functional API and UI test automation, with support for accessibility automation and test management.
Many, many more – A huge range of test automation products are available for teams to choose from based on their preferences and needs of their software delivery process.
Automated unit test writing
As you can see from these examples, many functional testing tools are at least somewhat concerned with testing the user interface and overall user experience, potentially across a complete application.
Unit testing, on the other hand, is in essence a ‘coding problem’. Every unit test is code that a developer – not the QA team – must write, compile, and run. When executed, each test confirms whether a single unit of code – one method, for example – behaves differently after a change has been made (thus indicating a potential regression).
Unlike functional testing, you don’t actually see that the button turns pink instead of red, or that the loan approval confirmation letter is actually a decline letter. You only see that the behavior of a specific part of your code is (or isn’t) as expected.
This means ‘software test automation tools’ – even with elements of AI built in – cannot fully automate unit testing because they don’t write code (remember: unit testing is a coding problem).
Such tools may help you to run unit tests as part of your testing process. But execution is just a part of the process, and in most cases automating it is not a big win compared to the effort involved in writing and maintaining the actual tests.
However, new tools are enabling developers to massively accelerate the process of unit test writing so they can spend more time working on value-adding code changes.
The level of automation – and hence benefit – of these tools varies. Boilerplate generators like DevMate create frameworks for the developer to complete. Pair programming tools like GitHub Copilot use AI to automatically suggest code – including unit tests – based on inputs provided by a developer. Diffblue Cover, meanwhile, is an AI for code tool that writes and maintains entire Java unit test suites.
Fully automated Java unit test writing
When it comes to modern CI pipelines (or even modern waterfall techniques) more automation typically means more value for development teams. Diffblue Cover uses reinforcement learning AI to autonomously write human-readable Java unit tests across entire Java projects.
Capable of writing as many tests in 8 hours as a human can in a year, with no manual intervention required, and of updating those tests automatically every time a code change is made, it enables the shift left that’s intrinsic to shorter cycle times.
Cover complements the existing functional test automation tools used by QA teams. It helps them to get more done and focus on the most important testing tasks by detecting regressions before code changes come their way.
To see for yourself what Diffblue Cover can do, try it for free today. Or to learn more about how Cover can become part of your test automation toolkit, speak to one of our team.
