I have a Go application with a number of unit and benchmark tests both in the root and in a subfolder called "message".
I execute the following command to run all unit tests from the root including the ones in the messages and any other subfolder:
go test ./...
I want to achieve the same for the benchmark tests, i.e. run them all. The following works for the ones in the root directory:
go test -bench .
The benchmark tests in the /messages folder are ignored which is expected. So I run the following from the root:
go test -bench ./...
That's not recognised at all, Go seems to execute the unit tests that are located in the root dir. I even tried to specify the message folder in the command as follows:
go test -bench ./message
...but it also failed. Currently if I want to run the benchmark tests in the message folder I have to cd into that folder and execute
go test -bench .
like above.
So what's the correct way then? How can I tell Go to find the benchmark tests both in the root and the subfolders? How does the regexp arg work in the case of the -bench flag? Apparently it's different from the regexp for the unit test runner.
You should use ./... to bench all the files from the current working directory and all of its subdirectories. If you wish to get a more verbose output you can use the -v flag. Also it's good to list the memory allocation by using -benchmem.
go test -v ./... -bench=. -run=xxx -benchmem
-bench flag takes regex so to run all benchmarks (-bench .) in all packages: go test -bench=. ./...
I have a project structure like this:
pkg
|
--pkg.go
--pkg_test.go
--a.go
--a_test.go
--b.go
--b_test.go
--c.go
--c_test.go
I wish to get the coverage for all the source files belonging to the package i.e.(pkg.go, a.go, b.go and c.go). However, when I run:
go test -v pkg
tests are run for only 1/4 go files.
Is there any way I can test my package without moving all the test codes within one file and keeping the file structure intact ?
if your working directory is that of your package, to test all of the files you could run:
go test ./...
if you wanted to get test coverage, you could run:
go test ./... -cover
I'm the author of a utilty that makes compressing projects using zip a bit easier, especially when you have to compress regularly, such as for updating projects submitted to an application store (like Chrome's Web Store).
I'm attempting to make quite a few improvements, but have run into an issue, described below.
A Quick Overview
My utility's command format is similar to command OPTIONS DEST DIR1 {DIR2 DIR3 DIR4...}. It works by running zip -r DEST.zip DIR1; a fairly simple process. The benefit to my utility, however, is the ability to use a predetermined file (think .gitignore) to ignore specific files/directories, or files/directories which match a pattern.
It's pretty simple -- if the "ignorefile" exists in a target directory (DIR1, DIR2, DIR3, etc), my utility will add exclusions to the zip -r DEST.zip DIR1 command using the pattern -x some_file or -x some_dir/*.
The Issue
I am running into an issue with directory exclusion, however, and I can't quite figure out why (this is probably be because I am still quite the sh novice). I'll run through some examples:
Let's say that I want to ignore two things in my project directory: .git/* and .gitignore. Running command foo.zip project_dir builds the following command:
zip -r foo.zip project -x project/.git/\* -x project/.gitignore
Woohoo! Success! Well... not quite.
In this example, .gitignore is not added to the compressed output file, foo.zip. The directory, .git/*, and all of it's subdirectories (and files) are added to the compressed output file.
Manually running the command:
zip -r foo.zip project_dir -x project/.git/\* -x project/.gitignore
Works as expected, of course, so naturally I am pretty puzzled as to why my identical, but dynamically-built command, does not work.
Attempted Resolutions
I have attempted a few different methods of resolving this to no avail:
Removing -x project/.git/\* from the command, and instead adding each subdirectory and file within that directory, such as -x project/.git/config -x project/.git/HEAD, etc (including children of subdirectories)
Removing the backslash before the asterisk, so that the resulting exclusion option within the command is -x project/.git/*
Bashing my head on the keyboard in angst (I'm really surprised this didn't work, it usually does)
Some notes
My utility uses /bin/sh; I would prefer to keep it that way for maximum compatibility.
I am aware of the git archive feature -- my use of .git/* and .gitignore in the above example is simply as an example; my utility is not dependent on git nor is used exclusively for projects which are git repositories.
I suspected the problem would be in the evaluation of the generated command, since you said the same command when executed directly did right.
So as the comment section says, I think you already found the correct solution. This happens because if you run that variable directly, some things like globs can be expanded directly, instead of passed to the command. And arguments may be messed up, depending on the situation.
Yes, in that case:
eval $COMMAND
is the way to go.
Has anyone succeeded in generating code coverage for Go unit tests? I can't find a tool for that on the web.
Note that Go 1.2 (Q4 2013, rc1 is available) will now display test coverage results:
One major new feature of go test is that it can now compute and, with help from a new, separately installed "go tool cover" program, display test coverage results.
The cover tool is part of the go.tools subrepository. It can be installed by running
$ go get golang.org/x/tools/cmd/cover
The cover tool does two things.
First, when "go test" is given the -cover flag, it is run automatically to rewrite the source for the package and insert instrumentation statements. The test is then compiled and run as usual, and basic coverage statistics are reported:
$ go test -coverprofile fmtcoverage.html fmt
ok fmt 0.060s coverage: 91.4% of statements
$
Second, for more detailed reports, different flags to "go test" can create a coverage profile file, which the cover program, invoked with "go tool cover", can then analyze.
Frank Shearar mentions:
The latest versions of Go (2013/09/19) use:
go test -coverprofile <filename> <package name>
Details on how to generate and analyze coverage statistics can be found by running the commands
$ go help testflag
$ go tool cover -help
Ivan Black mentions in the comments:
go test -coverprofile cover.out and then
go tool cover -html=cover.out opens cover.out in your default browser
I don't even want to wait for the browser to open, so I defined this alias:
alias gc=grep -v -e " 1$" cover.out
That I just type gc, and have a list of all the lines not yet covered (here: with a coverage.out line not ending with " 1").
Update 2022, possibly for Go 1.19
proposal: extend Go's code coverage testing to include applications
While the existing "go test" based coverage workflow will continue to be supported, the proposal is to add coverage as a new build mode for "go build".
In the same way that users can build a race-detector instrumented executable using "go build -race", it will be possible to build a coverage-instrumented executable using "go build -cover".
Merging coverage profiles produced in different GOOS/GOARCH environments will be supported.
Go comes with awesome tool for testing and coverage. Although all Go tools are well documented go tool cover -help I would suggest reading The cover story article on the official Go blog. It has plenty of examples and I strongly recommend it!
I have this function in my ~/.bash_profile. (you can just paste it in the terminal to give it a try).
cover () {
t="/tmp/go-cover.$$.tmp"
go test -coverprofile=$t $# && go tool cover -html=$t && unlink $t
}
Then just cd into a go project/package folder and type cover.
This opens a visual tool in browser which shows you the tested and untested code for each file in the current package. Very useful command! I strongly recommend it for finding what is not 100% tested yet! The shown results are per file. From a drop down in top-left you can see results for all files.
With this command you can also check the coverage of any package for example:
cover fmt
The output in terminal from this command would be:
ok fmt 0.031s coverage: 91.9% of statements
In addition to that in your browser you will see this tool showing in red all lines of code which are not covered with tests:
It is also possible to just save the html coverage file instead of opening it in a browser. This is very useful in cases when your tests + coverage is run by CI tool like Jenkins. That way you can serve the coverage files from a central server and the whole team will be able to see the coverage results for each build.
In addition to the good answers above, I find these three lines to be the simplest way to get it (which includes all packages):
go test -v -coverprofile cover.out ./YOUR_CODE_FOLDER/...
go tool cover -html cover.out -o cover.html
open cover.html
Note that in the HTML file you will find a dropdown button that will direct you to all files.
See go tool cover -help for additional options.
Simply run
go test -cover
or
go test -cover ./...
or
go test -coverprofile=coverage.out ./... ; go tool cover -func=coverage.out
or to check the source code
go test -coverprofile=coverage.out ./... ; go tool cover -html=coverage.out
I can't find a tool for that on the web.
Actually... there is now (2022) such a tool on the web, from Nikolay Dubina's project go-cover-treemap-web:
https://go-cover-treemap.io/
Nothing it uploaded (the processing remains local), but by dragging/dropping your coverprofile, the Web UI (using Go WASM) will run go-cover-treemap and display:
(gocovergage for https://github.com/gohugoio/hugo)
Coverage Report:
a) Run all the tests and enable coverage --> go test ./... -coverprofile coverage.out
b) Get coverage for individual functions as well as overall coverage → go tool cover -func coverage.out
c) See the lines covered and the ones not covered by your tests → go tool cover -html=coverage.out -o coverage.html. Open the coverage.html file hereby generated in the browser and analyze the detailed coverage info.
Already built-in in VSCode
Ctrl+Shift+P to Open Command Palette
Go: Toggle Test Coverage ...
The Green part is tested and Red is not
It's right here, some docs here.
$ go tool
6a
6c
6g
6l
addr2line
api
cgo
cov
dist
ebnflint
fix
gotype
nm
objdump
pack
pprof
prof
vet
yacc
$ go tool cov -h
usage: cov [-lsv] [-g substring] [-m minlines] [6.out args...]
-g specifies pattern of interesting functions or files
go tool cov: exit status 1
$
I haven't used it, this is all I know.
If you like to see the uncovered lines by function directly in a terminal I rewrote the cover tool for this purpose. It's available at https://github.com/gregoryv/uncover.
Usage
go get -u github.com/gregoryv/uncover/...
go test -coverprofile /tmp/c.out
uncover /tmp/c.out
Screenshot
If you are using VSCode this functionality is supported out the box ( But disabled by default )
Just turn on test on save + coverage reporting
https://github.com/microsoft/vscode-go/wiki/On-Save-features
It will even show in your editor which lines are not covered which is super handy.
If you want to find test coverage in Windows, just go to the desired folder in command prompt and type the following command:
go test -coverprofile=coverage.out && go tool cover -html=coverage.out
This is perfectly easy and works reliably.
Inspired by the help menus and other answers to this question, just run:
f=cover.out
if [ -f $f ]; then
rm $f
fi
go test ./... -coverprofile $f && \
go tool cover -html $f && \
rm $f
A quick and easy way is to use the coverage tool that comes with built-in go :
$ go test -coverprofile cp.out
// Emits the coverage in one liner percentage wise
After you execute the above command, if you wish to visually see the code coverage (like covered statements and missed etc)
$ go tool cover -html=cp.out
Note : You need to execute the above commands in the folder where you wish to see coverage
Try using gaia-docker/base-go-build Docker Image.
This is a Docker image that contains all you need in order to build and test coverage.
Running test coverage inside a Docker container creates .cover folder with test coverage results of your project.
docker run --rm -v "$PWD":$PROJECT_PATH -w $PROJECT_PATH $BUILDER_IMAGE_NAME /go/script/coverage.sh
The test coverage script running on all projects' folders and generates, inside .cover folder junit and coverage reports for each folder, and a combine coverage report of all projects' tests.
Codecov also suggests a script that collect coverage results: multiple files
Test Coverage for Golang
go get github.com/axw/gocov/gocov
go get -u gopkg.in/matm/v1/gocov-html
Check It is Installed Correctly And you have access from your Terminal
Run the Test Case
If you run the test case it will Reder the .json File Based on the file you will get the Code Coverage Report in .html file
gocov test >your_Coverage_report.json
Once Your Test case is done Generate a Report in .html File using .json
gocov-html your_Coverage_report.json >your_Coverage_report.html
Reference
GoTest Coverage Tool for go lang
Go Test Report Tool
Alternate Method
Go Native Test coverage
go test -coverprofile=coverage.out
go tool cover -html=coverage.out
I am looking for some documentation or tutorial for copying files from a given directory into the app created by xcode at build time, before it is run.
At first I have tried to copy files into the derived directory, hoping that everything resides in there would be automatically added to the app, but I was wrong.
So I am looking for a script because the original dir may change its name, second the script could be customized by another xcode 4 user with its src dir path etc.
The things is I don't know how to start, which language etc. I am quite confident with shell script, but maybe there's a better option.
Second, I am trying to figure out which command could add a file in the already built app.
thanks
That answer didn't really help - the BUILT_PRODUCT_DIR isn't where most stuff goes.
Ultimately, I found you just need to do:
Add the following to the very end of your script (or get your script to write directly to the output location):
cp ${DERIVED_FILE_DIR}/[YOUR OUTPUT FILES] ${BUILT_PRODUCTS_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}
...but there's a lot of other things I tried. More thoughts and ideas here: http://red-glasses.com/index.php/tutorials/xcode4-a-script-that-creates-adds-files-to-your-project/
You want a Run Script or Copy Files build phase. Select your main project in the navigator, then select the app's target. Click the Build Phases tab. Click the Add Build Phase button at the bottom of the window and choose the appropriate phase.
By "appropriate" I mean if you really want to run a script, you'll use a Run Script build phase and use Xcode-provided environment variables like $BUILT_PRODUCT_DIR (see the documentation or hit build and examine the full output of an empty script in the build log) to figure out your target folder. If all you want to do is copy files (no real processing), the Copy Files build phase already knows how to locate the app bundle's proper folders depending on what you're copying (Resources, Frameworks, etc.).