My project-structure
stuff/stuff.go -> package: stuff
test/stuff/stuff_test.go -> package: test
Although stuff_test executes code from stuff.go it shows
coverage: 0.0% of statements
I used
go test -cover
If I move my *_test.go to the stuff-folder of the program it is working fine.
Or perhaps my approach of the project-structure is not well designed/go-conform?
Conventional Go program structure keeps the tests with the package. Like this:
project
|-stuff
|--stuff.go
|--stuff_test.go
At the top of your testing files you still declare package stuff, and it is required that your test methods take the form TestMethodX if you want go test to automatically run them.
See Go docs for details: https://golang.org/pkg/testing/
Cross-package test coverage is not directly supported, but several people have built wrappers to merge individual coverage profiles.
See Issue #6909 for the long history on this. And see gotestcover for an example tool to do the merging. There's also gocovmerge. I built my own version, so I haven't tried any of these, but I'm sure they all work like mine, and mine works fine.
My sense is that this is just an issue that no one has written a really compelling changelist for, and hasn't been that important to the core maintainers, so it hasn't been addressed. It does raise little corner cases that might break existing tests, so the quick hacks that work for most of us haven't been accepted as-is. But I haven't seen any discussion suggesting the core maintainers actively object to this feature.
You can use the -coverpkg option to select the packages for which to record coverage information.
From the output of go help testflag:
-coverpkg pattern1,pattern2,pattern3
Apply coverage analysis in each test to packages matching the patterns.
The default is for each test to analyze only the package being tested.
See 'go help packages' for a description of package patterns.
Sets -cover.
For example:
go test ./test/... -coverprofile=cover.out -coverpkg ./...
Then view the report with:
go tool cover -html=cover.out
Related
I'm evaluating ginkgo at the moment - I very much like the BDD style.
However I'm unable at the moment to get the VS Code debugger to work with the framework. The official VS-Code extension provides test-by-test debugging for native go tests using CodeLens. With other languages and frameworks (eg Typescript/Mocha), I've been able to debug individual test files by setting up launch.json appropriately, but have been unable to find suitable examples for go.
Does anybody have any examples of any launch.json setups for debugging ginkgo tests (or go code invoked from any other framework)?
Thanks!
After a bit of playing around I found a way forward which perhaps should have been obvious. In case it isn't I'll leave the question and this answer here:
For a package foo, a foo_suite_test.go file is generated by the gingko bootstrap command. This contains a top-level test called TestFoo which runs the rest of the tests within the package.
This does have a CodeLens run test | debug test section above it which you can use to debug the entire suite.
It's not quite as convenient as the individual CodeLens entries which appear over each native go test, but it's easy enough to isolate specific tests to run using the Gingko F prefix.
I'm trying to figure out if there's a way to see what tests cover the functions in my Go code. I'm working on a code base with other developers so I didn't write all the tests/code myself.
I see some functions that are partially covered, or almost entirely covered, but they have no references anywhere (in its own, or other packages), and the functions aren't called directly in any of the tests.
Is there a way I can find which tests are covering that specific code? When I've tried to find if it's possible, all I get are articles showing how to write/run tests and get coverage percentages/highlighting, but nothing that actually shows if it's possible at all.
For the record, I'm using VS Code on linux and running go test ./... -cover in my terminals, as well as Ctrl+Shift+P -> "Go: Toggle Test Coverage In Current Package" for coverage highlighting within VS Code.
With the fuller picture in view now, via comments, it seems that you have a mess of tests, written by someone(s) less experienced with Go, and your goal is to clean up the tests to follow standard Go conventions.
If I were faced with that task, my strategy would probably be to disable all tests in the repository, by using a build tag that never gets executed, such as:
// +build skip
package foo
Confirm that all tests are disabled, by running go test ./... -cover, and confirm that you have 0% coverage everywhere.
Then, test by test, I would move each test into its proper place, and put it in a new file without the skip build tag.
If it's a big project, I'd probably do one package at a time, or in some other small, logical steps, to avoid a monster pull request. Use your own judgement here.
I'd also strongly resist the urge to do any other cleanups or fixes simultaneously. My goal would be to make each PR a simple copy-paste, so review is trivial, and I'd save a list of other cleanups I discover, to do afterward.
We write code, and we write tests. When you write tests, you're thinking about both the expected usage of the thing you're testing - and you're also thinking about the internal implementation of that thing, writing your test to try exposing bad behaviors.
Whenever you change the implementation of the thing, you're adding new lines of code, and sometimes it's difficult to be sure that your test actually exercises all the code in the thing. One thing you can do is set a breakpoint, and step through painstakingly. Sometimes you have to. But I'm looking for a faster, better way to ensure all the code has been tested.
Imagine setting a breakpoint and stepping through the code, but every line that was run gets highlighted and stays highlighted after it was run. So when the program finishes, you can easily look at the code and identify lines which were never run during your test.
Is there some kind of tool, extension, add-in, or something out there, that will let you run a program or test, and identify which lines were executed and which were not? This is useful for improving the quality of tests.
I am using Visual Studio and Xamarin Studio, but even if a tool like this exists for different languages and different IDE's, having that information will be helpful to find analogous answers on the IDE's and languages that I personally care about.
As paddy responded in a comment (not sure why it wasn't an answer), the term you're looking for is coverage. It's a pretty critical tool to pair with unit testing obviously because if some code isn't covered by a test and never runs, you'd want to know so you can more completely test. Of course, the pitfall is that knowing THAT a line of code was touched doesn't automatically tell you HOW the line was touched - you can have 100% test coverage without covering 100% of use cases of a particular LOC - maybe you have an inline conditional where one bit never gets hit, just as an example.
Coverage is also useful to know even outside of testing. By performing a coverage analysis on code in production, you can get a feel for what aspects of your codebase are most critical in real use and where you need to focus on bugfixing, testing, and robustness. Similarly, if there are areas of your codebase that rarely or never get hit in a statistically significant period of production uptime, maybe that piece of the codebase can or should get trimmed out.
dotCover and dotTrace seem like they'll probably put you on the right path. Coming from use in Python, I know I used to use Django-Nose, which comes with coverage testing and reporting integrated. There's coverage.py for standalone analysis, and of course these aren't the only tools in the ecosystem, just the ones I used.
Finding it difficult to express myself easily around this issue so thought best to start with a context section:
Context:
I have a Flex based application (a rather complex system) that can be compiled using "conditional compilation" into various use cases eg:
Compilation One = portalProjectUserOne
Compilation two = portalProjectUserTwo
Whether using conditional compilation is a sound idea is a completly different argument and therefore lets assume one is forced down this road, I then however decide to create a project for each of my desired compilations:
portalProjectUserOne
-branches
-tags
-trunk
-src
-pom
portalProjectUserTwo
-branches
-tags
-trunk
-src
-{NEEDS TO USE PROJECT ONES SOURCE}
As I do not want to break the ever rigid laws of programming and not duplicate anything I need a way of accessing the source of project ONE and using the source to do a CUSTOM compilation.
Things I have tried:
I tried using relative paths (../../portalProjectUserOne/trunk/src/etc...) with successful compilation but when it came time to release a final product to the nexus repo it had a few issues with reaching out the project structure, that and it felt a bit dirty really.
I attempted to use the "maven-dependency-plugin" to try and copy the sources from the first project, maybe this a pure lack of understanding on my part but I can not get my head around how you generate your classes in one project and access them from another.
This is my first question on stackoverflow and if I have been far to broad please let me know and I shall update with more extensive examples if required.
Thanks for listening/reading/being a coder.
The interactive environment is VERY helpful for a programmer. However, it seems Go does not provide it. Is my understanding correct?
No, Go does not provide a REPL(read–eval–print loop).
However, as already mentioned, Go Playground is very handy. The Go Authors are also thinking about adding a feature-rich editor to it.
If you want something local, consider installing hsandbox. Running it simply with hsandbox go will split your terminal screen (with screen) where you can write code at the top and see its execution output at the bottom on every save.
There was a gotry among standard Go commands, which used to evaluate expressions (with an optional package name), and could be run like gotry 1+2 and gotry fmt 'Println("hello")' from shell. It is no longer available because not many people actually used it.
I have also seen third party projects for building a REPL for Go, but now I can only find links to two of them: igo and go-repl. How well do they work I don't know.
My two cents: Speed of compilation makes writing a REPL possible for Go, as it has also helped building the tools mentioned here, but the same speed makes REPL less necessary. Every time I want to test something in Go that I can't run in Playground I open a simple .go file and start coding and simply run the code. This will be even easier when the go command in Go 1 makes one-command build process possible and way easier.
UPDATE: Latest weekly release of Go added go command which can be used to very easily build a file: write your prog.go file and run go build prog.go && ./prog
UPDATE 2: With Go 1 you can directly run go programs with go run filename.go
UPDATE 3: gore is a new project which seems interesting.
Try motemen/gore
Yet another Go REPL that works nicely. Featured with line editing,
code completion, and more.
https://github.com/motemen/gore
You also have a recent (March 2013) project called gore from Sriram Srinivasan, which can be useful:
gore is a command-line evaluator for golang code -- a REPL without a loop, if you will.
It is a replacement for the go playground, while making it much easier to interactively try out bits of code: gore automatically supplies boiler-plate code such as import and package declarations and a main function wrapper.
Also, since it runs on your own computer, no code is rejected on security grounds (unlike go playground's safe sandbox mode).
If you're a Vim user, the vim-go plugin (https://github.com/fatih/vim-go) provides a command (GoRun) to run and print the output of the current buffer. You still have to include all the boilerplate code of a main Go file, but it still provides a convenient way to quickly test code snippets in your local environment.
Have you tried the Go Playground?
About the Go Playground
The Go Playground is a web service that runs on golang.org's servers.
The service receives a Go program, compiles, links, and runs the
program inside a sandbox, then returns the output.
The GoSpeccy project includes a builtin REPL of a restricted subset of the Go language. The implementation is using goeval.
No, but you can exploit the speed of compilation (as mentioned in other answers).
Have a look at rango that uses a generate-compile-run loop to mimic a REPL. You can also start it with imports and statements to begin an interactive session.
Gosh is the interactive Golang shell. The goal is to provide an easy-to-use interactive execution environment.
https://github.com/mkouhei/gosh
I've had some luck with the VSCode debugger, but it's fairly limited in so far as you cannot invoke function calls from the debug console Debug: Function Calls not supported #2225.
Basically you set a breakpoint after properly configuring your launch.json file. Then you can drill down on the left in the variables side bar and enter variable expressions an the debug console.
You may also like to try https://github.com/haya14busa/goplay
This enables you to run go code files from your terminal directly to the Go Playground
Please also check www.gorepl.com for go REPL and other REPLs
Go code can be run in a REPL-like way in Visual Studio Code with the Go extension and Code Runner extension. Click the Run triangle ▶ which is marked by the mouse cursor in the below screenshot to run the code and show the results in the Output pane at the bottom of Visual Studio Code.
When programming with Go Visual Studio Code will suggest additional Go extensions that can be installed to extend Visual Studio Code's functionality.