eating one's own dog food tastes especially bad in this case - suite_context_test.go and run_test.go

[Johnlon]

@vearutop Looking for your support and encouragement here.

I've been trying to make a change and especially fighting the two files named in the title.
I am no 'frady cat' but using godog to write features and glue to test godog isn't a good idea IMHO.
I think thay have become incomprehensible and hard to maintain.

A simple change ought to be simple to make and test - I'm finding this case it's not.

The recursive nature of these tests (godog within godog) makes it hard to trace, understand and really hard to debug.
And if there a bug then is the bug with the wrapper godog code or the inner godog code? - I don't think its a great idea to use oneself to test oneself.

Anyway contrast this with your own (?) much better fmt_output_test.go style which uses features files in and sample files for expectations and there really is no comparison on maintainability.

Whilst the recursive thing is bad enough I think what really kills is that those two files are just a humongous bunch of undifferentiated step code. Not at all cohesive - the other tests aren't like this.

There is even the outdated comment below in the files that make changing anything scary as it seems to be that this code is exported for others to use - I think this is an especially bad idea.

What I'd like to do is one of ...

• tease the two files apart so that unrelated the steps arent' just slammed into one file and maybe scope them privately inside functions so they are closed off as much as possible
• or my preference I think is change all these tests to be more like fmt_output_test.go.

But there's that scary comment below, I suppose at a worse case those steps could just be orphanned in godogs code base and exported as they are now for whoever these other "add-on libraries" are ?
Who are these 'add-on' libraries?

// InitializeScenario provides steps for godog suite execution and
// can be used for meta-testing of godog features/steps themselves.
//
// Beware, steps or their definitions might change without backward
// compatibility guarantees. A typical user of the godog library should never
// need this, rather it is provided for those developing add-on libraries for godog.
//
// For an example of how to use, see godog's own `features/` and `suite_test.go`.

[Johnlon]

might feel different about this after the test refactoring I'm doing .

let's see

[Johnlon]

Refactoring work in progress - #659