Hit ~80% code coverage on all packages in this repo

[whyrusleeping]

In order to make releases more painless, and the code more stable and dependable in general I would like to try and hit a goal of at least 80% coverage (line based) on all packages.

Coverage data for master branch is at: https://codecov.io/gh/ipfs/go-ipfs/tree/master/cmd/ipfs

[whyrusleeping]

To check the code coverage on a given package, for example, unixfs/mod, run:

$ go test -v -cover ./unixfs/mod
=== RUN   TestDagModifierBasic
--- PASS: TestDagModifierBasic (0.01s)
        dagmodifier_test.go:131: Testing mod within zero block
        dagmodifier_test.go:137: Testing mod within bounds of existing multiblock file.
        dagmodifier_test.go:144: Testing mod that extends file.
        dagmodifier_test.go:150: Testing pure append
=== RUN   TestMultiWrite
--- PASS: TestMultiWrite (0.00s)
=== RUN   TestMultiWriteAndFlush
--- PASS: TestMultiWriteAndFlush (0.00s)
=== RUN   TestWriteNewFile
--- PASS: TestWriteNewFile (0.00s)
=== RUN   TestMultiWriteCoal
--- PASS: TestMultiWriteCoal (0.00s)
=== RUN   TestLargeWriteChunks
--- PASS: TestLargeWriteChunks (0.47s)
=== RUN   TestDagTruncate
--- PASS: TestDagTruncate (0.00s)
=== RUN   TestSparseWrite
--- PASS: TestSparseWrite (0.00s)
=== RUN   TestSeekPastEndWrite
--- PASS: TestSeekPastEndWrite (0.00s)
PASS
coverage: 75.2% of statements
ok      github.com/ipfs/go-ipfs/unixfs/mod      0.483s

That will show you all the tests that run, and at the end, a percentage of coverage for that package. To get more detailed info, you can generate a coverage profile like so:

$ go test -v -coverprofile=cover.out ./unixfs/mod

This will produce the same output as the last command, but it will also create a file called cover.out which you can use to generate a nice html coverage report:

$ go tool cover -html=cover.out

For more information, read through: https://blog.golang.org/cover

[jbenet]

Would be nice to write a script to output code coverage of a package and it's deps. Like the list you made but with the percentage next to it or something.

I'm sure there's some CI service that does it. Does project-repos.ipfs.io already incorporate go code coverage? cc @RichardLitt On Tue, Aug 9, 2016 at 15:45 Jeromy Johnson notifications@github.com wrote:

To check the code coverage on a given package, for example, unixfs/mod, run:

$ go test -v -cover ./unixfs/mod === RUN TestDagModifierBasic --- PASS: TestDagModifierBasic (0.01s) dagmodifier_test.go:131: Testing mod within zero block dagmodifier_test.go:137: Testing mod within bounds of existing multiblock file. dagmodifier_test.go:144: Testing mod that extends file. dagmodifier_test.go:150: Testing pure append === RUN TestMultiWrite --- PASS: TestMultiWrite (0.00s) === RUN TestMultiWriteAndFlush --- PASS: TestMultiWriteAndFlush (0.00s) === RUN TestWriteNewFile --- PASS: TestWriteNewFile (0.00s) === RUN TestMultiWriteCoal --- PASS: TestMultiWriteCoal (0.00s) === RUN TestLargeWriteChunks --- PASS: TestLargeWriteChunks (0.47s) === RUN TestDagTruncate --- PASS: TestDagTruncate (0.00s) === RUN TestSparseWrite --- PASS: TestSparseWrite (0.00s) === RUN TestSeekPastEndWrite --- PASS: TestSeekPastEndWrite (0.00s) PASS coverage: 75.2% of statements ok github.com/ipfs/go-ipfs/unixfs/mod 0.483s

That will show you all the tests that run, and at the end, a percentage of coverage for that package. To get more detailed info, you can generate a coverage profile like so:

$ go test -v -coverprofile=cover.out ./unixfs/mod

This will produce the same output as the last command, but it will also create a file called cover.out which you can use to generate a nice html coverage report:

$ go tool cover -html=cover.out

For more information, read through: https://blog.golang.org/cover

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ipfs/go-ipfs/issues/3053#issuecomment-238668573, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIcoQi1NlTIBRokThi-syQdWEmsSmoYks5qeNi3gaJpZM4Jekn_ .

[RichardLitt]

It doesn't, unless that is counted by CI. We should include it!

[whyrusleeping]

We can use coveralls for the go projects

On Wed, Aug 10, 2016 at 8:13 PM Richard Littauer notifications@github.com wrote:

It doesn't, unless that is counted by CI. We should include it!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ipfs/go-ipfs/issues/3053#issuecomment-239062950, or mute the thread https://github.com/notifications/unsubscribe-auth/ABL4HE96U2lM5unbwddoABxmYa9YU86kks5qepNfgaJpZM4Jekn_ .

[Kubuxu]

I made a script for go-ipfs: https://gist.github.com/Kubuxu/989ab1b51a9f3a0b71479a71abe35427#file-makereprot-sh it should be easily modifiable for other packages, but we should use CoverAlls (or something similar either way).

Someone just needs to go through all go repos and set it up.

[RichardLitt]

I'm happy to help with that?

[Kubuxu]

Sure, let's try it first on go-ipfs and we will see how it goes.

[Kubuxu]

We go unittest coverage on Codecov right now: https://codecov.io/gh/ipfs/go-ipfs I am working on sharness coverage to be published to Codecov in the https://github.com/ipfs/go-ipfs/pull/3504

[Kubuxu]

Sharness test coverage is done, all of your coverage is at: https://codecov.io/gh/ipfs/go-ipfs/tree/master/

There are lots of places to improve there, if you want to get to know the project structure better, it is great place to start.

[whyrusleeping]

@Kubuxu this is fantastic :)

Going to bump this issue to 0.4.7, but i'd say significant progress has been made

[wigy-opensource-developer]

Here are my 2 cents that you might safely ignore: Improving coverage in cmd will come best from pushing code duplicated all around that package into testable methods and functions. Also, some of that functionality should be moved behind the core api to improve reusability in other applications. End-to-end tests are much slower and harder to maintain, because they might break for quite many reasons not related to the goal of that given test.

[RichardLitt]

Here are my 2 cents that you might safely ignore:

All advice is listened to. :) Thanks for adding your 2 cents.

[whyrusleeping]

@wigy-opensource-developer Yeah, youre right. Code in the commands lib needs to be purely 'interface' code that translates user input into function arguments, and turns the codes responses into output.

[whyrusleeping]

Since the 0.4.6 we've seen a very small increase in overall code coverage

https://codecov.io/gh/ipfs/go-ipfs/compare/release...master

Lets aim for a higher target next release

[whyrusleeping]

Since 0.4.7, we've seen a 0.5% increase in overall code coverage:

https://codecov.io/gh/ipfs/go-ipfs/compare/c21c85f...1d59331

Thats better than the previous increase, but still pretty small. I'd love to see a 5% increase on the next release.

[whyrusleeping]

Since 0.4.8, we actually dropped a little bit: https://codecov.io/gh/ipfs/go-ipfs/compare/8e7484ed794d1aecb3e773e9003ae64c7b78bb87...a6e96e6c99c4240427af6c3bd9a9ca1b4cea99b4

:/