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

Output when using go test #68

Closed
valentin-krasontovitsch opened this issue Mar 21, 2017 · 4 comments
Closed

Output when using go test #68

valentin-krasontovitsch opened this issue Mar 21, 2017 · 4 comments

Comments

@valentin-krasontovitsch

When using go test to run godog features as described in the readme (using
TestMain), when the tests are successful, I don't get any output about which
features / steps are run in case of success, but I do get output for example
from a gin http server running as part of the test suite.

Is this intended behavior?

@l3pp4rd
Copy link
Member

l3pp4rd commented Mar 21, 2017

Hi, depends on what exactly are you seeing, for example godog itself has a test suite integrated in TestMain with a progress format. So when you run it:

2017-03-21-130539

Note, you do not see the exact scenarios printed since it is a progress format. If you change it to pretty then you will get all details.

func TestMain(m *testing.M) {
	status := RunWithOptions("godog", func(s *Suite) {
		SuiteContext(s)
	}, Options{
		Format:      "pretty",
		Paths:       []string{"features/load.feature:22"}, // only one scenario for this example
	})

	if st := m.Run(); st > status {
		status = st
	}
	os.Exit(status)
}

2017-03-21-131103

That is the intended behavior. If you are seeing different things then give me more context about your environment..

Additionally, you can leverage -v option which go test is using and change the formatter based on that:

func TestMain(m *testing.M) {
	format := "progress"
	for _, arg := range os.Args[1:] {
		if arg == "-test.v=true" { // go test transforms -v option
			format = "pretty"
			break
		}
	}
	status := RunWithOptions("godog", func(s *Suite) {
		SuiteContext(s)
	}, Options{
		Format: format,
		Paths:  []string{"features/load.feature:22"},
	})

	if st := m.Run(); st > status {
		status = st
	}
	os.Exit(status)
}

And then instead of progress if -v option is used, you would get pretty printed features and detailed go test command output.

2017-03-21-132042

@valentin-krasontovitsch
Copy link
Author

Thanks for the prompt feedback, very helpful!
Indeed my setup was using the format progress, and I'm getting all the desired output when using pretty.

I also just noticed that I was a bit imprecise:

I'm actually using go test $(glide novendor) to run the test suite without running tests that might be included in vendored packages in the subfolder vendor/. In my case, the project is very simple, so glide novendor just returns . - and running go test . gives me just

ok      gitlab.knf.local/ngs/gpp        0.015s [no tests to run]

The no tests to run is due to the fact that I only have features, and just have a TestMain that runs those features. But even when I add a dummy test, I still have the same output behavior: Just one line when I call go test .

Running go test gives me all the desired output. Running go test -v . also solves the problem, i.e. I get all the output I need without running tests I don't want to run.

Was just wondering if anybody had an explanation for the difference in output behavior of go test when called with a directory, and when called on its own.

As this is actually a question about go test, I'm gonna go ahead and close the issue.

@valentin-krasontovitsch
Copy link
Author

Turns out that this is normal behavior - go test . tests the package found in . and testing packages prints out a summary for each package, which in the case of one package results in a one-liner... got this answer on Stackoverflow.

@l3pp4rd
Copy link
Member

l3pp4rd commented Mar 23, 2017

thanks for getting back with the answer reference, might be useful for someone else. If there would be a failure in package while running go test . then you would get detailed error, see bellow.

2017-03-23-144356

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants