tests in different folders - godog with more than one TestMain

[martin-flower]

I can run tests using the command godog, and go test (with TestMain)

If I have two feature files, I can put them in separate folders, and run each one separately in their folder with godog or go test.

I can run both from the parent folder using go test ./...

I don't seem to be able to run all tests from the parent folder (was hoping that godog ./... would do this).

I am prevented from having all my tests in the same folder due to having more than one TestMain.

How can I split up my tests into different files and folders?

In order to run the tests in the release pipeline, I would like to build everything into one executable using godog -o

What is the best way forward?

[martin-flower]

Currently it looks like I can choose between two options

1. All the tests are in the same package - build one executable for running tests in the release pipeline without including godog binary in the application under test
2. Tests in separate packages; go test ./...; need to include godog binary in the application under test

I'm going with option 1 - at least the features are well separated, even if the implementations are not

[lonnblad]

Hi, sorry for not answering here as well, but I guess we took it in real life.

As I understand the problem;
there is a need to run godog with different test configurations, therefor the need to use multiple TestMain. This would now result in multiple test runs, which creates multiple results and a CI system would prefer one result.

@martin-flower could you elaborate a bit more on why you need multiple TestMain?

[martin-flower]

Let me see .. this was some time ago.

The question I think was splitting up the tests into different go packages. At the moment all tests are in the same package. I would like to organise my code in different folders that focus on different parts of the application under test. And to be able to execute these tests from continuous integration with the test results visible in the test result tab. As happens with go test ./...

In addition, there was the question about not having the godog runtime in the build artifact.

In summary, I think the outcome of the investigation was to have all godog tests in the same package - sharing one TestMain.

[gernotstarke]

It's imho violating separation-of-concerns to keep everything in a single package... In a reasonably large golang application, I definitely want my go source to be partitioned into several packages - but want to keep my specifications and features for the application in a single features directory...

I did not get that to work - having multiple _test.go files with godog glue code results in

InitializeScenario redeclared in this block

So it seems I can only put ALL step definitions into one (very very large) _test.go file (oops - don't want to do that),
or can write scenarios for a single package only... (which imho violates the idea of higher-level scenarios/features).

[mdelapenya]

I ended up creating different directories per test suite: https://github.com/elastic/e2e-testing/tree/master/e2e/_suites

• _suites
  • suite1
    • main_test.go
  • suite2
    • main_test.go

[gernotstarke]

your e2e repo is an awesome example - thanx for this pointer!!