Go to test coverage, if the statement is not covered

php editor Baicao will introduce you to a method of testing coverage today. In the software development process, test coverage is an important indicator, which can help us evaluate the degree of code coverage by test cases. And if we find that there are statements that are not covered, we can solve this problem through some means. In this article, we will explore how to test coverage and how to deal with uncovered statements.

Question content

I have a go function called setupConfig() and I have a Test_setupconfig to test it and it tests fine. But when I tested it for coverage and looked at the HTML report, it showed that my handling of some errors returned by the Viper package were not covered. Why isn't this covered? How should I handle this?

Solution

The coverage report tells you how much code was executed during the test. What you're seeing is that the if statements in these return blocks are not tested, which means you don't have any unit tests designed to fail and return an error. While testing that your code works when given correct input, it's also important to ensure that tests fail correctly and safely when given incorrect input.

However, this is a strange situation because these errors are not in your own package, these errors come from the viper package. At this point, it's important to ask yourself the question "What am I really testing?". If you use the viper package, then it's assumed that the package is thoroughly tested, and by creating your own tests for viper bugs, you're just doubling on those tests without real improvement. For this reason, sometimes we choose to omit testing these branches, because realistically, if the viper package is wrong - and assuming all your inputs are static and hardcoded like shown - then it's not a problem with your code , but it is a problem with the viper library.

If you really want to get 100% coverage and test all decision trees, the only way is to put the viper package behind some abstraction. Most likely it's an interface passed into the function, allowing for multiple implementations whether you're running in production or testing.

Having said that, it is not recommended to hardcode all the values ​​in the function like this. Ideally, you want the configuration structure's values ​​to come from local configuration files, environment variables, command line flags, or a combination thereof. By doing this, you make this setup function accept an interface for retrieving the configuration, making the function easy to test since all you need to do is mock the implementation of the interface in your test. So it will look like this:

config.go：

type ConfigController interface {
    GetInput() Config
}

func setupConfig(controller ConfigController) error {
    config := controller.GetInput()
    // your code here
}

config_test.go：

type mockConfigController struct {}

func (m *mockConfigController) GetConfig() Config {
    return Config{
        // your config here
    }
}

func Test_setupConfig(t *testing.T) {
    configController := &mockConfigController{}
    err := setupConfig(configController)
    // rest of test here
}

By doing this and providing an accept interface for your setupConfig() function, this means you can provide a function implementation for it when running in production, but also hardcode it when running tests test data to simulate it. It is also often used when interacting with other services, such as databases. Instead of having to start the database and connect to it when you run the test, you can have your code accept an interface that tells it how to interact with the database and simulate it in your tests. This allows you to isolate parts of your code and test only what you want.

The above is the detailed content of Go to test coverage, if the statement is not covered. For more information, please follow other related articles on the PHP Chinese website!