{"id":6665,"date":"2023-06-15T14:55:00","date_gmt":"2023-06-15T14:55:00","guid":{"rendered":"https:\/\/grid.gg\/?p=6665"},"modified":"2024-04-18T15:40:34","modified_gmt":"2024-04-18T13:40:34","slug":"testing-in-go-best-practices-and-tips","status":"publish","type":"post","link":"https:\/\/grid.gg\/testing-in-go-best-practices-and-tips\/","title":{"rendered":"Testing in Go: Best Practices and Tips"},"content":{"rendered":"\n
The writing of tests is a pretty big part of the average microservice\u2019s development cycle. Not only is it good for catching current and future issues in our code early, but it also works as a way to document the code\u2019s expected behavior.<\/p>\n\n\n\n
Maintaining high stability and consistency is especially important in GRID\u2019s management of real-time data, as issues can be difficult to detect and undo in time for delivery. In many cases, the original data will simply not be available for a redo, so any misstep the live data takes can be critical.<\/p>\n\n\n\n
To maintain a high level of test coverage we write our Go tests utilizing the built-in testing<\/mark><\/code> package, as it is very rich in features and it makes our tests easy to write.<\/p>\n\n\n\n
In this article we\u2019ll share some of our practices for Go testing that may help one write more manageable and reliable tests, as well as a healthier code base.<\/p>\n\n\n\n
Use the built-in testing<\/mark><\/code> package<\/h4>\n\n\n\n
To start with, we need to use the provided built-in testing<\/mark><\/code> package. To add a unit test to a function for example, add a testing file to the same package as the function to be tested. By convention, the unit tests’ file should have the same name as your functions followed by _test<\/code> <\/mark>(e.g. foo_test.go<\/mark><\/code> for a file called foo.go<\/mark><\/code>).<\/p>\n\n\n\n
For a unit test to be recognized as such, the name of the test function should start with a prefix \u201cTest\u201d and should take *testing.T<\/mark><\/code> as its only parameter. By convention, the tests are usually named after the function that they’re testing (e.g. TestFoo<\/mark><\/code> for a function called Foo<\/mark><\/code>).<\/p>\n\n\n\n
Here\u2019s an example of a simple unit test of a functionFoo<\/mark><\/code><\/code>:<\/p>\n\n\n\n
To run one\u2019s tests, use the go test<\/mark><\/code> tool (append .\/...<\/mark><\/code> to run all packages in your current folder):<\/p>\n\n\n\n
\nfunc Test_Foo(t *testing.T) {\n var tests = []struct {\n name string\n input string\n want string\n }{\n {\"yellow should return color\", \"yellow\", \"color\"},\n {\"banana should return fruit\", \"banana\", \"fruit\"},\n {\"duck should return animal\", \"duck\", \"animal\"},\n }\n for _, test := range tests {\n t.Run(test.name, func(t *testing.T) {\n actual := Foo(test.input)\n if actual != test.want {\n t.Errorf(\"got %s, want %s\", actual, test.want)\n }\n })\n }\n}<\/code>\n<\/code><\/pre>\n\n\n\n
And here\u2019s an example of some tests structured using nested t.Run<\/mark><\/code> functions:<\/p>\n\n\n\n
Subtests called by the same testing function will, generally, run in series, and will run through all subtests even if an earlier subtest has failed. In the cases where one would prefer the tests to run in parallel there\u2019s instead the t.Parallel<\/code> <\/mark>method. t.Parallel<\/mark><\/code> is called the same way as t.Run<\/mark><\/code>, but all subtests of a single test function that is called using t.Parallel<\/mark><\/code><\/code> run at the same time. For completely isolated tests, using t.Parallel<\/mark><\/code><\/code> instead of t.Run<\/mark><\/code><\/code> is a good practice as it allows the testing framework to better utilize its available resources.<\/p>\n\n\n\n
Use the assert library<\/h4>\n\n\n\n
In addition to the built-in testing framework it is also highly recommended to use the github.com\/stretchr\/testify\/assert<\/mark><\/code> library. Using this library, one can make tests simpler and easier to read, mainly by simplifying complex checks for expected results. By simply passing the expected and actual values to a one-line function, the library will manage and log the checking of the result as well as marking the full test as failed on failure.<\/p>\n\n\n\n
Here\u2019s an example of how one might use assert.Equal<\/mark><\/code> function in a test:<\/p>\n\n\n\n
\nfunc Test_MyFunction(t *testing.T) { \n result := MyFunction() expected := \"some expected value\" \n assert.Equal(t, expected, result, \"they should be equal\") \n}<\/code>\n<\/code><\/pre>\n\n\n\n
The library also provides many other useful functions, such as <\/mark>assert.True<\/code><\/mark>, <\/mark>assert.Nil<\/code><\/mark>, <\/mark>assert.Error<\/code><\/mark>, <\/mark>assert.ElementsMatch<\/code><\/mark>, <\/mark>assert.WithinDuration<\/code><\/mark>, and many others.<\/p>\n\n\n\n
On failure the assert functions will generally let the test continue, allowing for multiple assert failures to be recorded in a single run of a test. In the cases where one would rather let the tests stop on failure there\u2019s an accompanying library github.com\/stretchr\/testify\/require<\/mark><\/code>, which performs the exact same checks as the assert library, but it instead stops the test on the first assert failure.<\/p>\n\n\n\n
Run coverage tests<\/h4>\n\n\n\n
To check one\u2019s tests\u2019 coverage and generate coverage reports, the go test<\/mark><\/code> command offers the -cover<\/mark><\/code> flag. When one runs tests with the -cover<\/mark><\/code><\/code> flag, Go will collect coverage data for the given code and generate a report that shows how much of the code was covered by the tests.<\/p>\n\n\n\n
Here\u2019s an example of running a coverage test on a simple project:<\/p>\n\n\n\n
\n$ go test -cover .\/...\nok MyProject 0.003s coverage: 50.0% of statements<\/code>\n<\/code><\/pre>\n\n\n\n
This runs all tests found in the given directory and responds with the percentage of code covered by the tests.<\/p>\n\n\n\n
Just getting the percentage is not always enough, as it can be hard to figure out what part of one\u2019s code is lacking in coverage. To get more detailed information out of the coverage test there\u2019s the -coverprofile<\/mark><\/code> flag. This flag allows one to specify a file to which the detailed coverage profile will be written. Using this profile one can generate a coverage report using the go tool cover<\/mark><\/code> command.<\/p>\n\n\n\n
Here\u2019s an example of a coverage report being generated, in this case an html report:<\/p>\n\n\n\n
\n$ go test -cover -coverprofile=coverage.profile\nok MyProject 0.003s coverage: 50.0% of statements\n$ go tool cover -html=coverage.profileUsing the coverage reports can more easily identify areas of one\u2019s code that are not covered by tests in a visual and customizable way.<\/code>\n<\/code><\/pre>\n\n\n\n
Check for race conditions in your tests<\/h4>\n\n\n\n
A common cause for flaky and unreliable tests is race conditions. These are cases where parallelized operations behave inconsistently depending on the condition in which they\u2019re run. For example, when run on a local machine or later run in a pipeline. In Go, these most often occur when working with goroutines, and they can be quite difficult to catch while implementing tests.<\/p>\n\n\n\n
To help detect instances of race conditions the go test<\/mark><\/code><\/code> command offers the -race<\/mark><\/code> flag. The flag adds data race detection for the tests. When one runs tests with this flag the testing tool will detect and notify if any data race occurs. If a data race is detected, it will report an error and provide information about the location of the race.<\/p>\n\n\n\n
Here\u2019s an example of a basic race condition, and how the testing tool detects it:<\/p>\n\n\n\n
\nfunc Test_MyFunction(t *testing.T) {\n expected := 4\n actual := expected\n go func() {\n actual = 5\n }()\n if expected != actual {\n t.Fail()\n }\n}<\/code>\n<\/code><\/pre>\n\n\n
\n<\/figure><\/div>\n\n\n
The tests that have race conditions are treated as failing tests and the logs show the location of the affected data and the goroutines that are involved.<\/p>\n\n\n\n
We hope these tips and best practices will help you along the way as you build your code, making your tests consistent and reliable, and saving you time in the long run. <\/p>\n\n\n\n
![\"\"](\"https:\/\/grid.gg\/wp-content\/uploads\/2023\/10\/image.png\")
<\/figure><\/div>\n\n\n