Multiple suites in one package?

[t3hmrman]

Is this possible?

I may just be mistaken on how I should be structuring my Go, but I have a project that looks like this

a/
|------a.go
|------a_suite_test.go
|------a_test.go
|------b.go

I'd lke to have a suite that ONLY tests the functionality in B (and requires different setup/teardown from tests in A)

Is this possible? I've read the docs up and down and it seems like multiple suites are possible, but I have no idea the axiomatic ginkgo way to do it. Maybe it's really obvious and I just missed it.

[onsi]

it depends on the context but, typically, a and b would be separate packages each with their own test suites.

however, you can easily add b_test.go (ginkgo generate b) and then add tests for b. Any setup/teardown done in BeforeSuite and AfterSuite in a_suite_test will be shared between the two, however you can add BeforeEaches and AfterEaches to the Describe block in b_test to add test setup that is specific to b alone.

[onsi]

Note, that there will still just be one test suite with some tests that cover a and some that cover b -- when you run ginkgo you'll just see a single suite run.

[t3hmrman]

Hey onsi,

First of all, I really love the package you guys have developed (sorry
couldn't resist saying it) -- I'm currently using the trifecta
(Ginkgo+Gomega+Agouti) and am absolutely loving it

Thanks for the clarification -- I did add b_test, etc (for example I have
an integration_test.go). Just wanted to make sure I wasn't using Ginkgo
wrong

Also, One thing I did try was to add a "Before Each" to the describe, but I
only want to do set up once for a whole bunch of tests. I ended up just
making the fixtures play well with each other (and loading everything in
the BeforeSuite), but I did try was:

Describe(L0) (
BeforeEach (L1)
Describe (L1) (
Describe (L2) (
Its...
)
)
AfterEach(L1)
)

What I was hoping was that the Before Each would happen only once for that
describe, but it happened for each of the nested describes (@ L3)... So I
guess that's not a thing.

My problem is solved -- feel free to close the ticket. I did see that if I
packaged the code separately I could have different suites, but the code is
really inter-related (and I would end up with a bunch of one file
packages), so I didn't... ("inter-related" sounds like "tightly-coupled"
but I promise it's not... there are just some type definitions I'm not sure
how to axiomatically factor out)

[onsi]

glad you're enjoying ginkgo+gomega+agouti :)

What you're describing is BeforeAll which Ginkgo does not have. There was a discussion of this here #70

You can emulate the behavior you want with a simple boolean, but I recommend against it.

Finally, the problem you're running into is a common pattern in Go. How to share types between packages that are inter-related? In general the answer is to pull out a third package containing all your shared types -- that tends to work fairly well. Though, depending on your contextm having one monolithic package need not be a bad thing.

[onsi]

One last thought before I close the issue. You could leave all your code in one package but build multiple test-only packages. I've seen that be useful sometimes (e.g. a separate integration suite)

[t3hmrman]

Right, I am trying to do BeforeAll. I was OK with moving my setup code to BeforeSuite though, so that was OK.

Yeah, so I considered moving the types into one package by itself, but that just seemed kind of clunky (and a one file import)... I decided to go wtith the monolithic package.

Moving the tests into their own packages is a great idea, that would get me the separation I want actually, and the file structure would actually be pretty good.

Thanks!

[timothysc]

@onsi
So this would be a nice RFE, b/c if you have testing infra libraries across multiple repos this behavior would be useful for extensiblity.

/cc @jayunit100

[nabbas-ca]

I want to write k8s controller/operator tests within 2 suites, one with envtest controlller manager initialized and listening, and one without. So I can have finegrained negative path testing. For example, I want to to be able to setup a mock k8s api with bad CRs(before the webhook is alive or registered), and see how my controller reacts to correct it , as unit tests.

This way, I can setup a set of suites, within the same package like this:

1- clean controller, no CRs preloaded
2- preloaded good CRs, setup controller after the CRs are created
3- preloaded bad CRs, setup controller after the CRs are created
.....

Is that possible? remember that envTest is expensive to start. making a BeforeEach at top level of tests that includes manager start, could be possiblle, but it means starting and stopping manager for every test.

[onsi]

hey @nabbas-ca I've opened a new issue here to track this.