Request for more information

[anmolbabu]

• I have for a long time used the default go test -cover and have seen it lacking in several practical use cases as expected(since it is known to be measuring the statement coverage not the useful branch coverage). I instantly fell in love with this tool most importantly as it not only provides branch coverage as a metric but also provides a way for the user to know the untested code paths... Is there a way also to suppress some of the warnings of un-tested code branches and raise the coverage?
• I see the issues section of the repo literally empty(compared to most other open source projects) which is more than awesome and most importantly also, I have almost got an instant help from @rillig on every github issue I have raised on this repo till date which is extremely awesome... But, just out of curiosity, is there a set of known issues grouped by their category that the is not documented for now?
• Can the information about the community that built this tool, users using this tool be shared in the docs?
• Can the information on some of the alternatives to this tool and why this tool was built outside of go test --cover instead of getting branch coverage as a way to measure code-coverage or at-least as an add-on in the default go test --cover not done?

apologies in advance if some of my questions don't make any sense, but I am just curious before using this tool for my project

[rillig]

Is there a way also to suppress some of the warnings?

No, there isn't. If you have a very specific use case, please tell me and provide more details than a mere "some of the warnings". Up to now I didn't really need this option. Or at least I didn't need it badly. I have already thought about rules like:

• It doesn't matter if the argument to the assert function is only ever true.

Up to now I wanted to keep gobco simple and clean, without having to invent a whole configuration language. Therefore I rather added tests that make these assertions fail, instead of suppressing the coverage information.

Is there a set of known issues?

No, there isn't. This project is quite small and only has very few users. That's the reason that there are so few issues. Sometimes I sprinkle the code with TODO or XXX markers, That's the only other source of known issues besides the GitHub issue tracker.

information about the community

As can be seen on this page, there's only 1 active developer (me). I don't know why I should publish this information redundantly. Why do you want to have this documented?

users using this tool

I won't document who uses this tool, simply because I cannot know. As long as I don't receive any feedback, I don't even know whether anyone uses this tool at all, besides me.

alternatives to this tool and why this tool was built outside of go test --cover

I don't know of any alternatives. At least not for Go.

The reason for making gobco a separate project from go test -cover was that the Go authors want to keep go test -cover minimal. This is documented in this Stack Overflow answer by me.

[anmolbabu]

No, there isn't. If you have a very specific use case, please tell me and provide more details than a mere "some of the warnings". Up to now I didn't really need this option. Or at least I didn't need it badly.

Yeah specific use cases are errors that occur due to the runtime environment in which the code is run. Like a disk crash or even non-availability of a port to start a REST server, etc... which are seemingly(atleast as far as I know) un-testable but if you have specific handling for these cases, then certainly the branch coverage would reduce... While I feel its no harm to explicitly show that such cases are not covered in code as detected by the coverage tool, it may be a nicer idea to cautiously also suppress such cases. The examples were only 2 but in reality there are many such cases... However, its only 2 different philosophies(suppressing messages for such cases vs making such cases explicitly known)... So, I don't really know which way is better but I just put it out as I encountered such a case..

No, there isn't. This project is quite small and only has very few users. That's the reason that there are so few issues. Sometimes I sprinkle the code with TODO or XXX markers, That's the only other source of known issues besides the GitHub issue tracker.

Ack. It actually makes sense. I just wanted to know about it before using it instead of go test -cover

As can be seen on this page, there's only 1 active developer (me). I don't know why I should publish this information redundantly. Why do you want to have this documented?I won't document who uses this tool, simply because I cannot know. As long as I don't receive any feedback, I don't even know whether anyone uses this tool at all, besides me.

Yeah I see only 1 active(3 in total) contributor. you are right... there's really no need to publish it redundantly. I have in the past been part of community projects that had only 1 contributor but were projects sponsored by enterprises and used by the contributing enterprise internally or even in their commercial products... So, I just was trying to see if this is 1 such case... but it makes sense to not document it if there's no info as to who's using this...

I don't know of any alternatives. At least not for Go.

Ack

The reason for making gobco a separate project from go test -cover was that the Go authors want to keep go test -cover minimal. This is documented in this Stack Overflow answer by me.

Sure.. thanks...

[rillig]

No, there isn't. If you have a very specific use case, please tell me and provide more details than a mere "some of the warnings". Up to now I didn't really need this option. Or at least I didn't need it badly.

Like a disk crash or even non-availability of a port to start a REST server

The disk crash may be possible to simulate. At least SQLite does it, but that's a C project, not Go.

The non-availability of a port should be easily testable. For starters, you could test with a port number below 1024, which should return EPERM on UNIX-like operating systems.

Another way to test this case is to start listening on a port during a test and then try to start your server on that same port. This should fail, and you can then test that the error is reported correctly.

In my pkglint project, I had a similarly tricky example where I wanted to chmod a file, and I needed a test where this chmod fails, even on Windows. I finally solved that situation by splitting the code into smaller, independent pieces. One of these pieces already assumes that the file exists, and thus I could trigger a file-not-found error.

If all that is not what you want, you can start experimenting by editing the gobco code itself. For example, in instrumenter.visitExprs, you can replace the code with this snippet:

if expr.Op.Precedence() == token.EQL.Precedence() {
    switch y := expr.Y.(type) {
    case *ast.Ident:
        if y.Name == "nil" {
            continue
        }
    }
    exprs[idx] = i.wrap(expr)
}

This will skip all comparisons where the right-hand side is the expression nil. By setting a breakpoint there you can inspect how the expressions are represented in the Go compiler, which will allow further experiments.

I just wanted to know about it before using it instead of go test -cover

I don't recommend to use gobco instead of go test -cover. For example, gobco doesn't instrument select statements. It also doesn't find functions or methods that are completely unused. For these cases, I still use go test -cover.