The surface area of a test is all the executed production code that happens within the “act” phase of a test. You can think of this as the code that the test covers, or the coverage of this single test.
We don’t normally measure or worry too much about surface area, but it’s a useful concept for discussing the variety of tests and understanding when our test suites need more work.
System tests have a large surface area: The “act” phase of a system test can involve multiple network requests, multiple distributed processes, database connections, and so on.
Unit tests have a small surface area, relative to system tests. The “act” phase of a unit test most likely won’t involve any interprocess communication, and will only exercise code in a handful of components at most. Generally speaking they do not access any operating system resources, like files or sockets.
There’s no “right” size of surface area
Tests with large surface areas tend to be “quicker” to write if you consider that a few lines of code can “cover” a huge chunk of your application.
But they also tend to be poor at pinpointing where errors occurred.
If you’re finding yourself spending time stepping through test executions, trying to figure out where and why a test broke, then it may be time to consider breaking those tests into tests with smaller surface areas.
The “assert” phase doesn’t count
Code that’s run in the assert phase isn’t part of your coverage. This is one reason why it’s possible to have 100% code coverage but still not have a fully-tested application. Being able to look at a test and understand where the assert phase ends and where the act phase beings is an important tool to understanding how confident you should be about a test suite.
— Written by Daniel Irvine on :date_long.