Hello!
Is it possible to stop tests if any at least one test failed?

$ ginkgo generate gossh
panic: Couldn't identify package import path

goroutine 1 [running]:
main.getPackageImportPath(0x210285088, 0x5)
        $HOME/src/github/gopath/src/github.com/onsi/ginkgo/ginkgo/templates.go:130 +0x110
main.generateSpec(0x7fff5fbff408, 0x5)

I put all my github code under $HOME/src/github. Because of go's directory requirements, I get around this by adding gopath under github, and have a src there. So, if you look at my PWD, I have two src dirs.

go test --include="regexp pattern" --exclude="regexp pattern"

Any folder matching the hierarchy should be skipped.

The title says it all. I'm trying to install this package on Windows 7 and I get the following:

PS C:\git\rest-golang-demo> go get github.com/onsi/ginkgo
# github.com/onsi/ginkgo/remote
C:\Git\rest-golang-demo\src\github.com\onsi\ginkgo\remote\output_interceptor.go:53: undefined: syscall.Dup2
C:\Git\rest-golang-demo\src\github.com\onsi\ginkgo\remote\output_interceptor.go:54:     undefined: syscall.Dup2
C:\Git\rest-golang-demo\src\github.com\onsi\ginkgo\remote\output_interceptor.go:56: undefined: syscall.Dup2
C:\Git\rest-golang-demo\src\github.com\onsi\ginkgo\remote\output_interceptor.go:57: undefined: syscall.Dup2
C:\Git\rest-golang-demo\src\github.com\onsi\ginkgo\remote\output_interceptor.go:63: undefined: syscall.Dup2
C:\Git\rest-golang-demo\src\github.com\onsi\ginkgo\remote\output_interceptor.go:64: undefined: syscall.Dup2

Hello,any plan to introduce mocking?

I have a rather long spec that I had to split up into multiple It steps for readability and maintainability. But since each step depends on the success of the previous one it's rather annoying to go through dozens of failed tests to get to the root cause.

So a Sequence could be a special kind of Description that stops the execution of its Its as soon as the first one fails.

What do you think?

I'd find it useful to see the total number of tests after everything runs successfully.
It gives you a sense of the project's test size.

42 tests completed.
Done, without errors.

whenI execute ginkgo ,it will run the whole use cases of a test suite:

root@test-ubunut-3:/home/share/go-yuki# ginkgo -v test/demo

Running Suite: Demo

Random Seed: 1395828075
Will run 2 of 2 specs

An application being started
can start an app successfully
/home/share/go-yuki/test/demo/demo_test.go:31

?

An application being started
expert string
/home/share/go-yuki/test/demo/demo_test.go:37
?
Ran 2 of 2 Specs in 0.004 seconds
SUCCESS! -- 2 Passed | 0 Failed | 0 Pending | 0 Skipped PASS

Ginkgo ran in 5.897129235s
Test Suite Passed

If I want to run a specified use case,like /home/share/go-yuki/test/demo/demo_test.go:37
It that possible? and How to do it?

Is it possible to reference testing.T in the tests? This is needed by gomock to create a new mock controller.

I was looking at the output from ginkgo -r path/to/some/package today and noticed that they always run in the same order -- the order they are specified in. Immediately I wondered if it was possible to randomize this order by providing a flag, but I wonder if always running suites in a random order would be better.

# this always runs in the same order, regardless of seed
± jf+tj |master ✓| → ~/go/bin/ginkgo -r src/cf src/generic
[1398899746] Cf Suite - 0/0 specs  SUCCESS! 51.25us PASS
[1398899746] Api Suite - 197/198 specs •••••••••••••••••••••••••••••••••••••••••••••••••P•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• SUCCESS! 1.448903263s PASS
[1398899746] Resources Suite - 5/5 specs ••••• SUCCESS! 730.215us PASS
[1398899746] API Strategy Suite - 13/13 specs ••••••••••••• SUCCESS! 381.388us PASS
... SNIP ...
[1398899746] Trace Suite - 4/4 specs •••• SUCCESS! 409.165us PASS
[1398899746] Generic Suite - 4/4 specs •••• SUCCESS! 108.819us PASS

It occurred to me that Ginkgo runs the specs in a random order and it would be nice if it ran all suites in a random order as well. I believe this would help prevent test pollution between suites and encourage users to not rely on global state.

Admittedly, this is something that an enterprising user of Ginkgo could do by listing all of their suites and randomizing them, but I think there might be a good argument for this behavior to be the default in Ginkgo.

Thoughts? Concerns? Is this TOO crazy? Not crazy enough?

In my directory structure, I have

rootFolder\myApp\src     {This is the parent for my app }
rootFolder\myApp\tests\unit {This is where my unit tests reside }

When I run ginkgo command with watch=true, it watches for any changes in my "tests\unit" folder, which is great. However, I would also like to be able to run the unit tests whenever I make changes to the src folder as well (a bit like grunt-cli).

Is this possible? How do I pass a list or folders to watch for changes?

Thanks
-Rao

Would it be possible to add a BeforeSuite() hook to do suite-wide setup.

Ex. authenticating into an API under test and doing some pre-test, non-polluting setup before Ginkgo spawns -nodes runners

I would be happy to work on a PR but I'm not sure where this aught to be added.

Something like:

ginkgo -cover -coverallsToken=YOUR_TOKEN -coverallsService=travis

I'd like to drop the -beta off of 1.0 soon (early May) and start working on 1.1.

Any thoughts/suggestions/reservations about the current DSL/functionality in 1.0? I'd like to avoid non-backwards-compatible changes moving forward, so now is the time to bring that sort of thing up.

What is an example, anyway? ;)

This will affect custom reporters in the wild, but the fix should be a simple find-and-replace rename.

The fix involves generating one coverprofile per node and then reconstituting the various coverprofiles into one file...

I have some code that looks roughly like this:

type User string

Ω(info.User).Should(Equal("guest"))

However, this leads to failures. Explicit casting helps:

type User string

Ω(string(info.User)).Should(Equal("guest"))

It may be that I'm too new to Go but I believe type aliases work the way I expect. But this is not the case with Ginkgo. So my theory is that the Equal matcher does type equality checking (not equivalence).

At first I thought that's how Go works and stopped using type aliases, even though they make a lot of sense in my library.

So, is it a Go limitation or a Ginkgo "feature"?

Gomock expects a TestReporter that is really just a subset of the methods implemented by GinkgoT. As such there is no longer a need for the gomocktestreporter. Users of gomock (and anything else that takes a testing.T-like interface) should simply use GinkgoT()

...to avoid accidently committing focused tests and CI not turning red (since it's not running all the tests)

When I have a test failure it looks like this

• Failure [0.009 seconds]
Query
(/Users/myself/Dev/workspace/myproject/app/main/core/src/101loops/hrd/e2e_query_test.go:8)
  multiple simple models
  (/Users/myself/Dev/workspace/myproject/app/main/core/src/101loops/hrd/e2e_query_test.go:20)
    counts entities [It]
    (/Users/myself/Dev/workspace/myproject/app/main/core/src/101loops/hrd/e2e_query_test.go:28)
    Expected
        <int>: 4
    to be ==
        <int>: 1
    /Users/myself/Dev/workspace/myproject/app/main/core/src/101loops/hrd/e2e_query_test.go:91

This is too much information. I usually only care about the very last line.

So of course I tried to change this myself. But to do so I had to modify printFailure and comment out the printing of the component code locations - just 1 line change. But it was quite tedious since I had to copy the whole original file and create my own reporter (since the stenographer is not configurable) as well.

Can't this be easier?

Ginkgo is great but would be even better if you could start it up with a regex or -r and leave it running, watching for file changes (test and production code) and rerunning the appropriate tests.

Something like

ginkgo -r -a

would be ideal.

In my global setup I get a reference to a db session.

func TestBooks(t *testing.T) {
    RegisterFailHandler(Fail)

    //Code to set up your infrastructure
    dbSession := ...

    RunSpecs(t, "Books Suite")
}

Then I my test I will like to use this reference.

It("does something", func() {
    foo, err := service.Run(dbSession)
    ...
})

How can I do this?

Maybe Ginkgo needs a beforeAll block to do this?

Sometimes its hard to debug issues like a hanging test when running in parallel because output is buffered.

It would be great if there was a way to have all output immediately streamed to the console, prefixed with the parrallelNode id.

Ginkgo's current parallel spec output leaves much to be desired. The CLI launches a number of spec processes in parallel, waits for them to finish, then blams the output of all the processes onto screen in one shot. Users get no output until the tests completely finish....

Currently slow test output looks (something) like:

.......
---------
. [SLOW TEST:0.00 seconds]
First Context 
  path/bar_test.go:123
    Second Context
    path/bar_test.go:223
      test description
      path/bar_test.go:226
---------
...................
---------
. [SLOW TEST:0.00 seconds]
First Context 
  other_package/foo_test.go:123
    Second Context
    other_package/foo_test.go:223
      test description
      other_package/foo_test.go:226
---------

Perhaps something like:

> --------------------
........
~
[SLOW TEST:0.00 seconds]
First Context 
  path/bar_test.go:123
    Second Context
    path/bar_test.go:223
      test description
      path/bar_test.go:226
< --------------------

ginkgo bootstrap and ginkgo generate create test files that import Ginkgo and Gomega into the top-level namespace with .

This will remain the default, but there will now be a new --nodot mode that will explicitly import all exported names from Ginkgo and Gomega into the top-level namespace in the bootstrap file.

In addition there will be a ginkgo nodot command that will find the bootstrap file (anything ending with suite_test.go) and update the nodot import section as new exported names are added (e.g. new matchers).

This isn't helpful:

Full Stack Trace
/Users/mr/workspace/personal/goworkspace/src/github.com/onsi/ginkgo/code_location.go:17 (0x8d1fb)
        com/onsi/ginkgo.generateCodeLocation: fullStackTrace := string(debug.Stack())
    /Users/mr/workspace/personal/goworkspace/src/github.com/onsi/ginkgo/runnable_node.go:57 (0x96ab9)
        com/onsi/ginkgo.func.008: codeLocation:   generateCodeLocation(2),
    /usr/local/Cellar/go/1.1.1/src/pkg/runtime/panic.c:229 (0x14921)
        panic: reflect·call(d->fn, (byte*)d->args, d->siz);
    /usr/local/Cellar/go/1.1.1/src/pkg/runtime/panic.c:487 (0x15093)
        panicstring: runtime·panic(err);
    /usr/local/Cellar/go/1.1.1/src/pkg/runtime/os_darwin.c:462 (0x13fa8)
        sigpanic: runtime·panicstring("invalid memory address or nil pointer dereference");
    /Users/mr/workspace/personal/goworkspace/src/github.com/mark-rushakoff/go_dhcp/server/server.go:35 (0x9831d)
        com/mark-rushakoff/go_dhcp/server.(*server).OnDiscover: s.responseAgent.Offer(xid, nil, nil, []dhcp.Option{})
    /Users/mr/workspace/personal/goworkspace/src/github.com/mark-rushakoff/go_dhcp/server/server_test.go:31 (0x33331)
        com/mark-rushakoff/go_dhcp/server_test.func.003: server.OnDiscover(nil, 5, []dhcp.Option{})
    /Users/mr/workspace/personal/goworkspace/src/github.com/onsi/ginkgo/runnable_node.go:66 (0x9576f)
        com/onsi/ginkgo.(*runnableNode).run: runnable.syncFunc()
    /Users/mr/workspace/personal/goworkspace/src/github.com/onsi/ginkgo/example.go:120 (0x92e85)
        com/onsi/ginkgo.(*example).runSample: outcome, failure := beforeEach.run()
    /Users/mr/workspace/personal/goworkspace/src/github.com/onsi/ginkgo/example.go:88 (0x92c8f)
        com/onsi/ginkgo.(*example).run: ex.state, ex.failure = ex.runSample(sample)
    /Users/mr/workspace/personal/goworkspace/src/github.com/onsi/ginkgo/example_collection.go:122 (0x94036)
        com/onsi/ginkgo.(*exampleCollection).run: example.run()
    /Users/mr/workspace/personal/goworkspace/src/github.com/onsi/ginkgo/suite.go:45 (0x95bb4)
        com/onsi/ginkgo.(*suite).run: suite.exampleCollection.run()
    /Users/mr/workspace/personal/goworkspace/src/github.com/onsi/ginkgo/ginkgo.go:26 (0x94a99)
        com/onsi/ginkgo.RunSpecsWithCustomReporter: globalSuite.run(t, description, reporters, config.GinkgoConfig)
    /Users/mr/workspace/personal/goworkspace/src/github.com/onsi/ginkgo/ginkgo.go:22 (0x949b5)
        com/onsi/ginkgo.RunSpecs: RunSpecsWithCustomReporter(t, description, []Reporter{newDefaultReporter(config.DefaultReporterConfig)})
    /Users/mr/workspace/personal/goworkspace/src/github.com/mark-rushakoff/go_dhcp/server/server_suite_test.go:12 (0x330d6)
        com/mark-rushakoff/go_dhcp/server_test.TestServer: RunSpecs(t, "Server Suite")
    /usr/local/Cellar/go/1.1.1/src/pkg/testing/testing.go:353 (0x2f34a)
        tRunner: test.F(t)
    /usr/local/Cellar/go/1.1.1/src/pkg/runtime/proc.c:1223 (0x18470)
        goexit: runtime·goexit(void)

This would be more helpful:

Full Stack Trace
    /Users/mr/workspace/personal/goworkspace/src/github.com/mark-rushakoff/go_dhcp/server/server.go:35 (0x9831d)
        com/mark-rushakoff/go_dhcp/server.(*server).OnDiscover: s.responseAgent.Offer(xid, nil, nil, []dhcp.Option{})
    /Users/mr/workspace/personal/goworkspace/src/github.com/mark-rushakoff/go_dhcp/server/server_test.go:31 (0x33331)
        com/mark-rushakoff/go_dhcp/server_test.func.003: server.OnDiscover(nil, 5, []dhcp.Option{})
        /Users/mr/workspace/personal/goworkspace/src/github.com/mark-rushakoff/go_dhcp/server/server_suite_test.go:12 (0x330d6)
        com/mark-rushakoff/go_dhcp/server_test.TestServer: RunSpecs(t, "Server Suite")

(Indentation is a little messed up but you get the idea.)

A naive solution may be to only show matches in the current directory. A slightly more clever solution may only remove standard packages and ginkgo.

Is there a mechanism within Gingko that would allow me GDB like debugging?

Please advise.

This might look like:

ginkgo -auto-nodes

When specified any packages with package names that match the passed in regular expression will be skipped (won't even be compiled/run).

I think the mocking style of testify(https://github.com/stretchr/testify) is more nature than gomock,is it possible to hook it's mock lib into ginkgo?

this will look something like:

ginkgo <flags> <packages> -- <arguments/flags to pass along>

If the timeout provided for an It() with a done channel is longer than the default 5 second timeout of slowSpecThreshold, it would be nice if we didn't have to modify the slowSpecThreshold for all tests to accommodate the one or two slow tests.

Also, it would be nice to have an option to skip known slow tests (i.e. the ones with a long timeout specified on the It())

I was very excited when I figured out that I can use Fail("should be unreachable") in a spec and it did the right thing. But that doesn't seem to be covered in the documentation.

Currently, writes to the GinkgoWriter performed during a failing BeforeSuite or AfterSuite don't make it to the screen.

Here's the planned behavior:

ginkgo onepackage will run with the standard reporter output
ginkgo firstpackage secondpackage will run in succinct mode
ginkgo -v firstpackage secondpackage will override succinct mode and run in verbose mode

As a part of this issue, Measurements will actually print out in succinct mode (they currently don't) though the output will be abbreviated.

Firstly, thanks for creating this wonderful tool.

The issue I am facing is when using ginkgo/gomega with gomock, specifically with the stack trace. For e.g., if I have a create order scenario

/**** This is test code in OrderService_test.go ****/
mockSession.EXPECT().SomeOperation(Order{Id : 2})
OrderService.Create(mockSession)

/**** This is application code in OrderService.go ***/
func (self *OrderService) Create(dbSession MySession) {
......

     orderId := 1
    dbSession.SomeOperation(Order{Id : orderId})
.....

}

If my input input does not exactly match, gomock ends up failing the expectation and stopping processing. However, by looking at the stack trace, I am only able to tell which test failed and I am not able to tell which line the expectation failed at (in my application source code). The stack trace does not indicate any line in the source code (OrderService here) and just gives me some output along the lines of

no matching expected call: []interface {}.%!v(MISSING)(%!v(MISSING))

which I presume is a gomock error. However, if I have a bunch of expectations in a test, then it is really difficult for me to know where the failure is unless I spray the _fmt.Print_ statements along the execution path (which is non ideal as it prevents me from making changes easily and confidently).

Thanks
-RV

PS : Hope I can raise this issue here as I read this article http://pivotallabs.com/using-ginkgo-with-gomock/

We added println to BeforeEach and JustBeforeEach and made a FIt. println from JustBeforeEach did not show up (unlike println from BeforeEach).

• @cppforlife, @dliebreich

A useful tool, but not particularly Ginkgo specific.

instead of

config.GinkgoConfig.ParallelNode

GinkgoParallelNode()

I may be missing something here, but I can't figure out why I get a panic if one of my assertions fails.

This is the panic I get:

test:
     [exec] panic: runtime error: invalid memory address or nil pointer dereference
     [exec] [signal 0xb code=0x1 addr=0x0 pc=0xb25ee]
     [exec] 
     [exec] goroutine 1 [running]:
     [exec] runtime.panic(0x2a4fa0, 0x60d779)
     [exec]     /usr/local/go/src/pkg/runtime/panic.c:266 +0xb6
     [exec] github.com/onsi/gomega.(*actual).match(0xc2100be480, 0x72aa50, 0x619980, 0x1, 0x0, ...)
     [exec]     /Users/neil/work/go/src/github.com/onsi/gomega/actual.go:61 +0x31e
     [exec] github.com/onsi/gomega.(*actual).To(0xc2100be480, 0x72aa50, 0x619980, 0x0, 0x0, ...)
     [exec]     /Users/neil/work/go/src/github.com/onsi/gomega/actual.go:33 +0x9a
     [exec] github.com/NeilGarb/budget/core_test.func·078()
     [exec]     /Users/neil/work/go/src/github.com/NeilGarb/budget/core/user_test.go:20 +0x3ea
     [exec] github.com/onsi/ginkgo.(*suite).pushContainerNode(0xc2100475a0, 0x34c070, 0x1a, 0x38d8d0, 0x0, ...)
     [exec]     /Users/neil/work/go/src/github.com/onsi/ginkgo/suite.go:69 +0x20e
     [exec] github.com/onsi/ginkgo.Context(0x34c070, 0x1a, 0x38d8d0, 0x1)
     [exec]     /Users/neil/work/go/src/github.com/onsi/ginkgo/ginkgo.go:214 +0x98
     [exec] github.com/NeilGarb/budget/core_test.func·079()
     [exec]     /Users/neil/work/go/src/github.com/NeilGarb/budget/core/user_test.go:21 +0x63
     [exec] github.com/onsi/ginkgo.(*suite).pushContainerNode(0xc2100475a0, 0x32b970, 0x13, 0x38d8d8, 0x0, ...)
     [exec]     /Users/neil/work/go/src/github.com/onsi/ginkgo/suite.go:69 +0x20e
     [exec] github.com/onsi/ginkgo.Describe(0x32b970, 0x13, 0x38d8d8, 0xc200000000)
     [exec]     /Users/neil/work/go/src/github.com/onsi/ginkgo/ginkgo.go:185 +0x98
     [exec] github.com/NeilGarb/budget/core_test.func·007()
     [exec]     /Users/neil/work/go/src/github.com/NeilGarb/budget/core/user_test.go:22 +0x3e
     [exec] github.com/onsi/ginkgo.(*suite).pushContainerNode(0xc2100475a0, 0x2fc8c0, 0x4, 0x38d7b0, 0x0, ...)
     [exec]     /Users/neil/work/go/src/github.com/onsi/ginkgo/suite.go:69 +0x20e
     [exec] github.com/onsi/ginkgo.Describe(0x2fc8c0, 0x4, 0x38d7b0, 0x42a01)
     [exec]     /Users/neil/work/go/src/github.com/onsi/ginkgo/ginkgo.go:185 +0x98
     [exec] github.com/NeilGarb/budget/core_test.init()
     [exec]     /Users/neil/work/go/src/github.com/NeilGarb/budget/core/user_test.go:78 +0x17b
     [exec] main.init()
     [exec]     github.com/NeilGarb/budget/core/_test/_testmain.go:108 +0x4a
     [exec] 
     [exec] Ginkgo ran in 1.816899343s
     [exec] Test Suite Failed

From the following piece of code:

var _ = Describe("User", func() {
    Describe("creating a new user", func() { // line 10
        Context("when not providing valid state", func() { 
            _, e := NewUser(nil)
            Ω(e).NotTo(BeNil())
        })
        Context("when providing valid state", func() { // line 15
            u, e := NewUser(Args{"first_name": "Neil", "last_name": "Garb"})
            Ω(e).To(BeNil())
            Ω(u).NotTo(BeNil())
            Ω(u.FirstName == "Neil").To(BeTrue())
            Ω(u.LastName == "Garb").To(BeTrue()) // line 20
        })
    })
    // ... snip ...
})

User is:

type User struct {
    Id        int        `json:"id"`
    FirstName string     `json:"first_name"`
    LastName  string     `json:"last_name"`
    Accounts  []*Account `json:"accounts"`
}

If any of the assertions inside the second Context() fail, I get that panic. I've used == instead of Equal() for no particular reason. I get the panic either way.

Using d3df15b, onsi/gomega@3da99a5 and go version go1.2.1 darwin/amd64.

I'm writing a test to make sure that one of my methods makes the correct request to a web server. It uses a lot of query parameters to do this which unfortunately look an awful lot like format strings.

A snippet of the code is below:

BeforeEach(func() {
    request = AddBookmarkRequest{
        URL: "http://google.com",
        Title: "Google Search",
        Description: "Seems like a cool underground site!",
        Tags: []string{"search", "mail", "maps"},
        CreatedAt: time.Now(),
        Replace: true,
        Shared: false,
    }
})

It("makes a request to add a bookmark", func() {
    client.AddBookmark(request)

    urlParams := url.Values{}
    urlParams.Set("format", "json")
    urlParams.Set("auth_token", "user:token")

    urlParams.Set("url", request.URL)
    urlParams.Set("description", request.Title)
    urlParams.Set("extended", request.Description)
    urlParams.Set("tags", strings.Join(request.Tags, ","))
    urlParams.Set("dt", request.CreatedAt.Format(time.RFC3339))
    urlParams.Set("replace", "yes")
    urlParams.Set("shared", "no")

    lastAddUrl := fmt.Sprintf("https://api.pinboard.in/v1/posts/add?%s", urlParams.Encode())
    Expect(httpClient.LastURLRequested).To(Equal(lastAddUrl))
})

lastAddUrl looks something like this at the end of this:

auth_token=user%3Atoken&description=Google+Search&dt=2013-10-20T22%3A13%3A13%2B01%3A00&extended=Seems+like+a+cool+underground+site%21&format=json&replace=yes&shared=no&tags=search%2Cmail%2Cmaps&url=http%3A%2F%2Fgoogle.com

Ginkgo reports the failure like so:

Looks (MISSING) funky.

If I have following result:
SUCCESS! -- 2 Passed | 0 Failed | 0 Pending | 0 Skipped PASS

1,Hope the color of number "2" before "Passed" can be set to green
2,if only the numbers(before "Passed","Failed","Pending","Skipped") were colored,result will be easier to read

While using Ginkgo I find myself often using FDescribe() while implementing a feature, and then wanting to use FIt() within the block to debug a specific assertion:

FDescribe("some behavior", func() {
    FIt("some assertion", func(){ ... })
    It("some other assertion", func(){ ... })
})

However, go test runs all of the specs in the container, not just the focused one. This seems counter-intuitive to me.

If you agree that focused specs should take precedence over focused spec containers, I'd be happy to send a PR.

is this normal?

spiff(master*): go test -v ./compare
=== RUN Test

Running Suite: Diffing
======================
Random Seed: 1377418446

Will run 13 of 14 specs

••••••••••P•••
Ran 13 of 14 Specs in 0.001 seconds
SUCCESS! -- 13 Passed | 0 Failed | 1 Pending | 0 Skipped

--- FAIL: Test (0.00 seconds)
FAIL
exit status 1
FAIL    github.com/vito/spiff/compare   0.047s

I was very surprised to discover that Ginkgo will only run the tests that are defined in the same package as the suite_test. Seems like a bug, but I would also accept that this is a feature (because it forces you to write your tests in the name_test package.

Alternatively, if this is hard to solve, a warning would be very nice.

A standard way for me is to run 'go run ' it would be great of ginkgo would support that to.

Hi! Really?