Writing better table-driven tests: pros and cons of different unit testing styles
Ever wondered what the best style for writing unit tests is? We at Symflower have a certain take on that. We developed a test style optimized towards debuggability, readability and understandability. This reduces the time spent on finding failing tests and understanding test cases, and therefore allows us to spend more time on actual development. We also created an extension for GoLand and Visual Studio Code to help us write those unit tests. Let’s take a look!
Symflower-style table-driven unit tests
In the beginning of Symflower, we were using the standard Go style for writing our table-driven tests. Over time we got increasingly unhappy with that style. The standard Go style for writing table-driven tests has the fundamental flaw that it takes quite a bit of time and effort to figure out which test cases are failing, when one looks at the
go test output and its stack traces. To resolve that problem, we developed our own unit testing style. By encapsulating the test cases in a call to a validation function, we were able to get meaningful stack traces for failing tests while still sticking to a table-driven style.
- Validation function
- Named test cases
- Structured test cases
- Meaningful stack traces for failing tests
- Improved readability and understandability by named and structured test cases
- Reuse of validation code
The main purpose of our style is an improvement in debuggability and readability. Both aspects help us spend less time on debugging tests and stay focused on actual coding.
Other test styles
There are, of course, other frequently used test styles out there. We’ll briefly showcase them for you, so that you have a proper base for comparing them with the Symflower style detailed above.
Function per test case
This is the most basic test style. Since every test case gets its own test function, there is a lot of redundant code, and the specific behavior that a test case should check is not described.
- Redundant validation code
- Overview of existing tests is not great
- Long and hard to read test function names
Standard Go style
This is the style you see most often in Go projects. It’s already table-driven, which is a huge improvement to the function-per-test-case style, since it reduces the amount of redundant code. However, there are still disadvantages, which are overcome by our style.
- No relevant stack traces for failing tests
- No description of the behavior the test cases should check
- Missing field names can make tests hard to follow
- More fields and data can make these tests very hard to read and maintain
Symflower for VS Code and GoLand
Through better readability and the benefits outlined above, using the right style can streamline your unit testing efforts and improve your overall productivity. That saves some time, of course – but what if you did not have to spend time writing those unit tests in the first place? Here at Symflower, we’ve developed an extension for VS Code and GoLand that automatically generates meaningful unit tests for you, even letting you choose the style in which they should be written.
If you’re performing TDD, you’ll find our unit test templates helpful, as they greatly reduce the time you have to spend writing boilerplate code. However, the major productivity-enhancing feature of Symflower is that it can automatically create unit tests with meaningful values that are integrated in your existing test suite. Ready to run unit tests are just a click away – give Symflower a whirl to see how it works!
Please drop us a line on our public issue tracker if you are missing a feature, found a bug, or just want to tell us how you like the extension and our unit test style.