Adding support for `testing.M`

[Olshansk]

Most of this library is build around testing.T which has a wrapper implementing the TestingT interface.

It doesn't seem like it would be too hard to add support for testing.M [1]. Before I investigate, I wanted to know if there are design and/or philosophical decisions to avoid spending time on this assuming it'd be practical from a technical standpoint?

The specific use-case I have in mind is in the use of dockertest, to change this:

func TestMain(m *testing.M) {
	pool, err := dockertest.NewPool("")
	if err != nil {
		log.Fatalf("Could not connect to docker: %s", err)
	}
...
}	

To this:

func TestMain(m *testing.M) {
	pool, err := dockertest.NewPool("")
        require.NoError(m, err)
...
}	

[1] Note that I did not try to implement it myself yet and am aware that practice will be harder than theory, but am open to looking into it.

[brackendawson]

testing.M has no way of stopping execution, you only have the choice of calling m.Run() or not calling m.Run(). What you are describing is impossible.

[Olshansk]

What if we call os.exit when there's an error? Since TestMain is kind of like a setup, it should prevent all further tests of executing.

[brackendawson]

You could do that. The assertion would have no need for you to pass it a testing.M, there is no m.Fatal() method so it's not going to use it for anything. You'd need to create a new package like require but without the need for a TestingT, and it would have to call os.Exit() itself, and it would now have to deal with printing its own messages to the console. I think it's hard to justify another copy of all the assertions for this.

[Olshansk]

Got it.

@brackendawson So in your opinion, should we just close this out as "won't do"?