tarp alternatives and similar packages
Based on the "Code Analysis" category.
Alternatively, view tarp alternatives based on common mentions on social networks and blogs.
-
Go Metalinter
Metalinter is a tool to automatically apply all static analysis tool and report their output in normalized form. -
go-cleanarch
Clean architecture validator for go, like a The Dependency Rule and interaction between packages in your Go projects. -
go-mod-outdated
Find outdated dependencies of your Go projects. go-mod-outdated provides a table view of the go list -u -m -json all command which lists all dependencies of a Go project and their available minor and patch updates. It also provides a way to filter indirect dependencies and dependencies without updates. -
goreturns
A gofmt/goimports-like tool for Go programmers that fills in Go return statements with zero values to match the func return types -
tickgit
Manage your repository's TODOs, tickets and checklists as config in your codebase. -
GoCover.io
GoCover.io offers the code coverage of any golang package as a service. -
apicompat
apicompat checks recent changes to a Go project for backwards incompatible changes -
ChainJacking
Find which of your direct GitHub dependencies is susceptible to RepoJacking attacks -
usestdlibvars
A linter that detect the possibility to use variables/constants from the Go standard library. -
staticcheck
staticcheck is go vet on steroids, applying a ton of static analysis checks you might be used to from tools like ReSharper for C#. -
gosimple
gosimple is a linter for Go source code that specialises on simplifying code. -
unused
unused checks Go code for unused constants, variables, functions and types. -
blanket
blanket is a tool that helps you catch functions which don't have direct unit tests in your Go packages. -
Golint online
Lints online Go source files on GitHub, Bitbucket and Google Project Hosting using the golint package.
Learn any GitHub repo in 59 seconds
Do you think we are missing an alternative of tarp or a related project?
Popular Comparisons
README
blanket
blanket
is a tool that helps you catch functions which don't have direct unit tests in your Go packages.
Installation
go get -u gitlab.com/verygoodsoftwarenotvirus/blanket
Docker Image
If you don't want to install blanket locally, you can use the pre-built Docker image like so:
docker run -it --rm -v "$(pwd):/src/<pkg>" verygoodsoftwarenotvirus/blanket:latest analyze --package <pkg>
Where <pkg>
could be something like gitlab.com/verygoodsoftwarenotvirus/blanket/analysis
. :)
Purpose
Say, for example, you had the following Go file:
package simple
func A() string {
return "A"
}
func B() string {
return "B"
}
func C() string {
return "C"
}
func wrapper() {
A()
B()
C()
}
and you had the following test for that file:
package simple
import (
"testing"
)
func TestA(t *testing.T) {
A()
}
func TestC(t *testing.T) {
C()
}
func TestWrapper(t *testing.T) {
wrapper()
}
Running go test -cover
on that package yields the following output:
PASS
coverage: 100.0% of statements
ok gitlab.com/verygoodsoftwarenotvirus/blanket/example_packages/simple 0.006s
However, note that B
doesn't have a direct test the way that A
and C
do. B
is only "tested" in TestWrapper
. Because all the functions are called, -cover
yields a 100% coverage value. If you ever decide that wrapper
doesn't need to call B
anymore, and don't delete the function entirely, you'll have a drop in coverage. Running blanket analyze
on that same package yields the following output:
Functions without direct unit tests:
in /Users/vgsnv/golang/src/gitlab.com/verygoodsoftwarenotvirus/blanket/example_packages/simple/main.go:
B on line 7
Grade: 75% (3/4 functions)
Additionally, you can use the cover
command to visualize those functions by passing in a cover profile. So if you run something like go test -coverprofile=coverage.out && blanket cover --html=coverage.out
, a browser window will open that shows untested functions in red, functions without direct tests in yellow, and functions that are directly tested in green, like so:
[example output](example_files/cover_screenshot.png)
Use Cases
What blanket
seeks to do is catch these sorts of things so that package maintainers can decide what the appropriate course of action is. If you're fine with it, that's cool. If you're not cool with it, then you know what needs to have tests added.
You can also use blanket
in your CI pipeline to decline PRs that would add functions that don't have direct unit tests. As a matter of fact, blanket
does just that for itself! Here is an example of such a scenario working on this very repository!
I think blanket
could also be helpful for new developers looking to contribute towards a project. They can run blanket
on the package and see if there are some functions they could easily add unit tests for, just to get their feet wet in a project.
Issues
If you've tried blanket on something and found that it didn't accurately handle some code, or panicked, please feel free to file an issue. Having an example of the code you experienced issues with is pretty crucial, so keep that in mind.
Known Issues
blanket
doesn't adequately handle deeply nested method calls. So if you had something like this:
package main
import (
"testing"
)
/*
// in another file:
type Example struct{}
func methodCall() {
return
}
*/
func TestMethod(t *testing.T) {
x := struct{
First: struct{
Second: struct{
Third: Example{},
},
},
}
x.First.Second.Third.methodCall()
}
That should technically satisfy blanket's strict testing requirement, but it doesn't. Blanket can handle single-level selector expressions with great ease, but it doesn't recursively dive into those selectors for a number of reasons.