What is test surface area?

Image of Daniel Irvine
Daniel Irvine

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.

The surface area includes any code that you didn’t write but is executed as part of library functions. This is important when we’re thinking about React. Unit tests for UI components have a much larger surface area than unit tests for Plain Ol’ JavaScript Objects, because they involve creating a DOM container, mounting and unmounting the component, and performing some actions on the DOM container. All of the work that React does to insert and delete HTML elements—that’s part of the surface area.

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.

Sign up to our new weekly newsletter and get free screencasts as a gift

Our weekly newsletter launches soon (we’re not quite ready yet). But you can sign up now. When it launches, we’ll send you 8 free screencasts showing how to go from 0 to 100 with test-driving React.