Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make passing of -test.v configurable #508

Closed
pohly opened this issue Jul 20, 2018 · 1 comment · May be fixed by #511
Closed

make passing of -test.v configurable #508

pohly opened this issue Jul 20, 2018 · 1 comment · May be fixed by #511

Comments

@pohly
Copy link
Contributor

pohly commented Jul 20, 2018

It looks like ginkgo always invokes Go test binaries with -test.v.

I think this is the code line where this is decided:

return t.run(t.cmd([]string{"-test.v"}, os.Stdout, 1), nil)

Should that perhaps only be added when running ginkgo -v?

I want to to use ginkgo as main test runner because then I can parallelize my rather large Ginkgo test suite while running some smaller, normal Go tests sequentially (but ideally, those would also run in parallel, see #280). Because output is large, I only want to see it when a test fails. I'm almost there, except for the -test.v...

pohly added a commit to pohly/ginkgo that referenced this issue Jul 25, 2018
"ginkgo" can replace "go test" as test runner also for normal Go
tests, but the output was different:
- tests were always run with -test.v and thus produced output
  also on success
- there was no indication of which test produced the output

Now the output behavior is closer to that of "go test":
- tests run in verbose mode only when "ginkgo -v" is used
- after each test, a line with "ok/FAIL <test path>" is
  printed

That line is not quite the same as in "go test", which prints the
import path, but close enough. That line is important when running in
quite mode, because without it one would not be able to tell what
tests were run. Even in verbose mode the output could be
ambiguous (for example, when different packages happen to contain the
same test).

Example:

$ go test ./pkg/log ./pkg/log/testlog
ok  	github.com/foo/bar/pkg/log	0.005s
--- FAIL: TestOutput2 (0.00s)
	testlog_test.go:40: INFO TestOutput2
	testlog_test.go:42: was asked to fail
FAIL
FAIL	github.com/foo/bar/pkg/log/testlog	1.417s

$ ginkgo ./pkg/log ./pkg/log/testlog
PASS
ok ./pkg/log
--- FAIL: TestOutput2 (0.00s)
	testlog_test.go:40: INFO TestOutput2
	testlog_test.go:42: was asked to fail
FAIL
FAIL ./pkg/log/testlog

Ginkgo ran 2 suites in 2.145256459s
Test Suite Failed

Fixes: onsi#508
pohly added a commit to pohly/ginkgo that referenced this issue Sep 11, 2018
"ginkgo" can replace "go test" as test runner also for normal Go
tests, but the output was different:
- tests were always run with -test.v and thus produced output
  also on success
- there was no indication of which test produced the output

Now the output behavior is closer to that of "go test":
- tests run in verbose mode only when "ginkgo -v" is used
- after each test, a line with "ok/FAIL <test path>" is
  printed

That line is not quite the same as in "go test", which prints the
import path, but close enough. That line is important when running in
quite mode, because without it one would not be able to tell what
tests were run. Even in verbose mode the output could be
ambiguous (for example, when different packages happen to contain the
same test).

Example:

$ go test ./pkg/log ./pkg/log/testlog
ok  	github.com/foo/bar/pkg/log	0.005s
--- FAIL: TestOutput2 (0.00s)
	testlog_test.go:40: INFO TestOutput2
	testlog_test.go:42: was asked to fail
FAIL
FAIL	github.com/foo/bar/pkg/log/testlog	1.417s

$ ginkgo ./pkg/log ./pkg/log/testlog
PASS
ok ./pkg/log
--- FAIL: TestOutput2 (0.00s)
	testlog_test.go:40: INFO TestOutput2
	testlog_test.go:42: was asked to fail
FAIL
FAIL ./pkg/log/testlog

Ginkgo ran 2 suites in 2.145256459s
Test Suite Failed

Fixes: onsi#508
@onsi
Copy link
Owner

onsi commented Apr 5, 2021

I'm working through the backlog of old Ginkgo issues - apologies as this issue is probably stale now.

I'm going to close this for now, but feel free to reopen it if you'd like.

@onsi onsi closed this as completed Apr 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants