Improving on unit test styles

Releases
#1

Hi Gophers!

We were unhappy with the common unit test styles and we think we found a style that has clear advantages. An in-depth comparison can be found here https://symflower.com/en/company/blog/2022/better-table-driven-testing/.

We also added support for maintaining such tests in our VS Code extension https://marketplace.visualstudio.com/items?itemName=symflower.symflower. You can either use the command or the context menu item to maintain tests.

There are some changes necessary to have better stack traces for because “t.Run” calls the test function from another location. We are in the process of upstreaming them.

Would appreciate your feedback on the style and extension. Would be also interesting to hear other approaches and conventions that could help others to write better tests.

Cheers,
Markus

2 Likes
#2

Hi @zimmskal ,

I have seen tons of unit test plugins/projects, this one clearly has some good points. My main concerns are:

  • how would a test look like if the validate function has complex logic (it is larger)
  • how would a table test look like when there are many test cases - how easy is that to follow

I like your initiative and this plugin, keep up the good work.

#3

First change for github.com/stretchr/testify has been pushed as a PR https://github.com/stretchr/testify/pull/1161: “Include locations of subtests in test failure stack traces”. Please give your emoji-support if you agree that this is a good behavior change.

1 Like
#4

Indeed it is larger but that would be the case no matter the testing style. It just depends on what one wants to check. In our case, it is also a sign for code/api to be refactored if the logic becomes too big (vs simple inputs/outputs).

One problem that often comes up for us is that with “complex objects” we cannot simple use the fields directly unless there is a constructor function. So we often write the initialization right before the “validate” call. How do you currently test code that has complex objects? (e.g. need multiple method calls to setup.)

We are using this style for years now and we found two scenarios to be extremely common:

  • The “validation” calls are sequential without grouping because the code is simple
  • The “validation” calls are grouped by categories and subcategories e.g. for our extension we group them into “Go” and “Java” test cases and subcategories for test styles and different errors.

Thank you, that is great to hear :slight_smile: If you have any requests or found a bug please let us know. We are currently working on getting our unit test generation (tests WITH inputs and outputs) on par with our Java support. So you can either use a generated test or write a manual one. Would be interested on what you think Tutorial - Symflower CLI

#5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.