By Melissa Eaden
The idea of “subcutaneous testing” has been around for a while. Even before Martin Fowler mentioned it on his blog, it can be seen referenced in a blog post from 2010 by Jimmy Bougard.
Bougard’s definition of a subcutaneous test:
“While a unit test focuses on small-scale design, a subcutaneous test does not address design, but instead tests basic inputs and outputs of the system as a whole.”
Our definition, which was developed by several members of our ThoughtWorks team, gives a more complete, technical picture of what the team was trying to accomplish with subcutaneous testing.
A Definition Of Subcutaneous Testing
“If a unit test is testing the smallest testable component of application code, then a subcutaneous test is a single workflow which can be identified and tested of the application code. Subcutaneous testing treats a workflow as a testable unit.”
Subcutaneous testing wasn’t a well-known testing method until recently. The first re-exposure to the idea was in a ThoughtWorks presentation given by Daniel Lafeir and Michael Lawrie. Since then, the model they introduced has gained traction with ThoughtWorks developers using Angular, React, and Vue as part of their tech stacks.
Introduction To A Radical Idea
When the developers Daniel Lafeir and Michael Lawrie explained they had a method to create functional tests which could replace more traditional UI level testing, the idea felt pretty radical and a bit magical.
As a tester who had embraced automation and the benefits, it was hard to imagine a world which UI tests were not necessary for functional testing. The idea they presented, wasn’t really eliminating a level of testing, but rather asking for the audience to think about testing in the right place and focusing the testing on what was necessary.
The ideas around what Daniel and Michael presented were starting to make sense. From a tester’s perspective, working with libraries and frameworks that use componentization and containers, the value of these kinds of tests present themselves easily. Subcutaneous style tests can speed up the information pipeline about an application, and it can reduce the reliance on UI driven tests for checking functionality.
Understanding what you can cover functionally, and how to create subcutaneous tests, adding this to your testing stack can be an amazing, responsive way of maintaining checks on functional interactions for an application.
What Subcutaneous Testing Is And Isn’t
There are some exceptions with subcutaneous testing. It’s not a direct substitute for automation testing via a browser. Subcutaneous testing is a more focused testing of functionality at the right level of an application. It allows a team to create better end-to-end tests using the existing code, framework, and/or libraries available for the front end application.
The main goal of this kind of testing is to reduce test flakiness and focus on functionality. This allows the team to differentiate between functional failures due to code issues verses application failures due to compatibility issues, or external dependency issues.
Since subcutaneous tests can be run with the same test framework as the unit tests, they don’t have access to the backend code or API calls while running. Isolating these tests and using mocking tools which can mimic API calls and stubbing for various service interactions can give a focused, isolated measure of the functionality in the front-end stack.
Testing the functionality in this manner allows any automation through the browser and UI to have a lighter touch. This means traditional UI tests might be very minimal and only test that connections are working between layers of an app.
- Instead of using expensive GUI and UI tests for information on functionality, they can be shallow level health checks or smoke tests.
- Avoiding the use of the UI automation asserting the expectation of something functionally working, the tests can assert if the app is communicating correctly across its integration layers. Or verify operational status.
Filling In The Gaps: Additional Testing You Might Need
Isolating issues and focused testing practices are very good goals to have for any testing approach. Subcutaneous testing allows for a focus on the functional without the noise of other dependencies. The focus on functional is very valuable, but testers shouldn’t lose sight of the other parts of the application which could require frameworks and tools to help give a complete picture of application health.
No browser, no screenshots. Screenshots are not available for this kind of testing. Where a lot of automation frameworks can give you screenshots of your UI, Subcutaneous testing doesn’t have this ability. There are very good tools that can do cross-browser and screenshots very rapidly. If you need these for visual checks, separating this to a tool designed to pull screenshots could be a better use of time. Sauce Labs is a good example. Other tools include Aplitools and CrossBrowserTesting from SmartBear.
Subcutaneous testing can’t really check compatibility issues for mobile or web browsers. It’s functional level end-to-end testing only. Compatibility checks or issues with browsers can only be checked manually or by creating UI automation tests. However, because tests are being executed at the functional level with more granular interactions, the UI level could do light compatibility checks with a tool or a web test harness. This would allow for isolation of compatibility problems.
Third-party integrations are hard to check with this kind of testing. If those integrations don’t use an API call of some kind, it might be necessary to do a UI check from a web framework. Examples might be Ad services or external widgets generated from outside of the application.
Advantages To UI Testing Using Subcutaneous Tests
Because subcutaneous testing uses all the components on a page, creating integrated tests that only test a few components or testing one component at the unit level might not be necessary. Unit tests can target more complicated logic rather than trying to test all the logic around one component, testing the core logic lightens the unit test burden.
Subcutaneous testing uses the same test framework (like Jest) as the unit tests. This keeps the functional tests internal and closer to the code which gives the team a greater chance of faster feedback and quicker test adjustment than a test framework maintained separately. This means teams don’t have to do extra work of maintaining several frameworks, repositories, and sometimes languages, to accomplish UI functional testing.
Now that Subcutaneous testing allows for functional testing of code rather than through the UI, any UI tests can be reduced to a small fraction of what was necessary previously. UI tests can be used like smoke tests. In this way, they can prove that the application and all its various layers are in a healthy, communicating state.
Failed UI tests become meaningful again because there are less of them, and less of them to maintain and they are only testing what is necessary to test. If there is a failure from a UI test, while the subcutaneous tests are passing, then it’s likely something major has happened with the pipeline, or the application, which is probably outside of the application’s control. Having that knowledge can speed up troubleshooting as you have already eliminated application functionality as a culprit.
When learning how to automate the UI via a testing framework, it can teach a tester a lot about how to build tests. It’s not very often a tester is able to receive feedback about UI test automation. It works or it doesn’t. Improvements in coding practice or code design can be slow and take more time.
Teaming up with developers and pairing on subcutaneous testing allows for the tester to learn more about code structure and learn a better test coding structure. Testers can exchange their test knowledge for coding general know-how. Developers can learn more about the testing mindset and risks they see for the application. For testers and developers that embrace these kinds of interactions, the learning curve might be steep, but can be beneficial and even rewarding.
Melissa Eaden has worked for more than a decade with tech companies such as Security Benefit, HomeAway, ThoughtWorks, and now Unity Technologies. Melissa’s previous career in mass media continues to lend itself to her current career endeavors. She enjoys being EditorBoss for Ministry of Testing, supporting their community mission for software testers globally. She can be found on Twitter and Slack @melthetester.
The ThoughtWorks team members referenced are Hany Elemary, Avalon McRae, Eric Huang, and Cliff Morehead.
You May Also Be Interested In:
- Exploratory Testing an API by Maaret Pyhäjärvi
- Introduction To HTTP course withMark Winteringham
- API Mocking and Service Virtualization Explained webinar with Wojciech Bulaty