Use new beforeEach signature in TestPrinters adapter

[rynoV]

A small update for compatibility with changes from haf/expecto#516

I believe this will need Expecto 11.0.0-alpha6 but will confirm when the PR is merged

[farlee2121]

PR is merged. Please let me know when you're ready to push a preview release so we can coordinate.
We'll want to document the versions that users will need to update together

[Alxandr]

I don't think I have the infra to produce preview releases atm I think 😓.

That being said, support for the new .NET testing platform just got merged, so combining those two into a breaking change might be a good way forward.

[farlee2121]

We've got some more breaking changes queued up on the Expecto side, so 11.x might not reach general audiences for a bit.

Looks like you're using Release Please?

[Alxandr]

Looks like you're using Release Please?

I am. Never had to use it to do pre-releases before though. I think it can be done by crafting a commit with a specific message, but it's not something I've ever tried.

That being said, nuget packages are created on every build, and could be uploaded to gh as artifacts; so it should be possible to download one of them and just drop them in a local nuget-store for testing.

[farlee2121]

I've been thinking, and I think requiring a coordinated version change is likely to cause trouble.
There should be some ways we can achieve compatibility.

For example, what if we make a multi-phase migration like this

Phase 1: Add a builder method or some other way consumers can create a TestPrinter that isolates them from change in the printer signature

Expecto.Impl.TestPrinters.silent
|> TestPrinters.withBeforeEach newBeforeEach
//...

Deploy that change in some Expecto 10.x release

Phase 2: YoloDev updates to use the builder method

Phase 3: Expecto update the printer type, using the builder method to map the old signature into the new one without disrupting callers of the builder method

Thoughts?

[farlee2121]

This wouldn't get us compatibility between all versions of Expecto and the YoloDev adapter, but it should reduce breakage going forward and also reduce the likelihood a consumer runs into the incompatibility

[farlee2121]

Here's the Expecto PR to add those builder methods (on the Expecto side)
I'm open to other approaches if y'all have ideas or concerns.

Once we decide on an approach, I'd be happy to push an Expecto update and make a PR here too

[Alxandr]

Thoughts?

That seems like a much better idea. If we can release a non-breaking version of YoloDev.Expecto.TestSdk that works with 10.x and will work with 11.x a few weeks (at least) before expecto 11, that is pretty likely to remove most issues people will run into.

Once 11 is out, we might also try to see if we can have tests in this repo against both 10 and 11 for a while.

[Alxandr]

@farlee2121 what's the latest? Is this still in progress? etc.

[farlee2121]

I think PR #210 probably makes this unnecessary.

Since the isSkipped parameter isn't used by this project, and this project is now using the builder methods, it shouldn't need to change anything else to work with Expecto 11.0.0.

[Alxandr]

So I just close this then?

[farlee2121]

@rynoV Do you have any outstanding concerns?

[rynoV]

Looks like #210 handles this nicely, thanks folks