Add supporting data to the json suite versus doing a before or after all

[dschveninger]

We are looking for a way to attach properties about the test suite instead of attaching properties to every test case.

I do not see a way in the documentation to do so, I was wondering if there is a way to do that or if it is something that you would consider as a future enhancement?

[dschveninger]

I was thinking of allowing a type that contained a map[string]sting being passed into RunSpecs to attaching it to the Suite for the Reporter to support attaching this metadata to the report type suite data?

It would be also nice it that key value pair slice be accessible to the specifications at run time some how.

[dschveninger]

We have been reviewing the code and we are thinking if the https://github.com/onsi/ginkgo/blob/d696c7b753a2107ccbe5ddbabaab256539a2d1fb/types/types.go#L15 Report would have a map[string]string called SuiteProperties we could add key vale pairs in the ReportBeforeSuite function.

My guess is we would also update https://github.com/onsi/ginkgo/blob/d696c7b753a2107ccbe5ddbabaab256539a2d1fb/reporters/junit_report.go#L83 to map this data to the junit format.

Does this sound like something you would be interest in doing?

[onsi]

hey @dschveninger - one approach that more-or-less works today is to use AddReportEntry in a (Synchronized)BeforeSuite. The BeforeSuite is only run once, at the beginning of the suite and generates a <testcase> in the JUnit file that has name="[BeforeSuite]" and a <system-err> that will include your properties. This code:

var _ = BeforeSuite(func() {
    AddReportEntry("Parameters", map[string]string{
        "A": "123",
        "B": "Marsupials",
    })
    AddReportEntry("Alternative-A", "123")
    AddReportEntry("Alternative-B", "Marsupials")
})

generates this <system-err> output:

> Enter [BeforeSuite] TOP-LEVEL - /Users/onsi/code/ginkgo/foo/foo_suite_test.go:15 @ 08/18/23 11:57:52.453
Parameters - /Users/onsi/code/ginkgo/foo/foo_suite_test.go:16 @ 08/18/23 11:57:52.453
  map[A:123 B:Marsupials]
Alternative-A - /Users/onsi/code/ginkgo/foo/foo_suite_test.go:20 @ 08/18/23 11:57:52.453
  123
Alternative-B - /Users/onsi/code/ginkgo/foo/foo_suite_test.go:21 @ 08/18/23 11:57:52.453
  Marsupials
< Exit [BeforeSuite] TOP-LEVEL - /Users/onsi/code/ginkgo/foo/foo_suite_test.go:15 @ 08/18/23 11:57:52.453 (0s)

(The output is even cleaner if you use Ginkgo's JSON format).

It would be also nice it that key value pair slice be accessible to the specifications at run time some how.

With the approach above this is achievable via something like:

var parameters map[string]string
var _ = BeforeSuite(func() {
        parameters = map[string]string{
        "A": "123",
        "B": "Marsupials",
        }
    AddReportEntry("Parameters", parameters)
})

• this is now available to all tests.

I'm open to a higher-level first-class construct as well. And I'd probably go with this approach:

I was thinking of allowing a type that contained a map[string]sting being passed into RunSpecs to attaching it to the Suite for the Reporter to support attaching this metadata to the report type suite data?

rather than this approach:

... we could add key vale pairs in the ReportBeforeSuite function.

As the ReportBeforeSuite function is given an immutable copy of the report.

The metadata would be stored on the Report object and could then be included in the JSON format (we basically get this for free as it is simply the JSON encoding of types.Report) and in the JUnitProperties field (as you propose ) for JUnit reports. The latter makes sense to me as the JUnit format doesn't specify any other place to put suite-level data like this.

So something like:

RunSpecs(t, "My Suite", SuiteMetadata(map[string]string{
    "A": "123",
    "B": "Marsupials",
}))

could work.

Does this sound like something you would be interest in doing?

I think I'd be happy to pull this in, along with documentation, but I'm not going to have much capacity to do it myself in the near future. If you'd prefer this first-class approach over the BeforeSuite approach and you're up for working on a PR that would be great!