feat: TestProvider for easy, parallel-safe testing

[warber]

This PR

• implements an idea how to improve possibility to write highly parallel unit tests.

Related Issues

Fixes: #293

[codecov]

Codecov Report

Attention: Patch coverage is 70.21277% with 14 lines in your changes missing coverage. Please review.

Project coverage is 81.45%. Comparing base (0b13f8a) to head (853d9f4).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/openfeaturetest/testprovider.go	70.21%	11 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #295      +/-   ##
==========================================
- Coverage   81.89%   81.45%   -0.44%     
==========================================
  Files          10       11       +1     
  Lines        1215     1262      +47     
==========================================
+ Hits          995     1028      +33     
- Misses        199      210      +11     
- Partials       21       24       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[warber]

I guess we need to come up with a better place for this ? 🤔

[aepfli]

the question is, if we want this to be part of the sdk or rather put this as a separate package in the sdk-contrib - like we did in java for the junit extension.

[warber]

then to me this sounds like contrib would be the better place. @toddbaert ?

[toddbaert]

Since there's no external deps, I think we should include this in the SDK.

[warber]

not perfect but does the trick of getting the current gid from the runtime

[natenho]

@warber to be honest it is a very hacky way of dealing with that. Maybe we can think of a more elegant solution since the go routine id is intentionally not available.

[toddbaert]

@warber to be honest it is a very hacky way of dealing with that. Maybe we can think of a more elegant solution since the go routine id is intentionally not available.

I agree it's hacky, however, there are multiple relatively popular packages that use this same mechanism, and we are only using it for testing. I would not advocate for including this in production code, but I think it's acceptable to dodge our singleton issue for tests, and include it only in a testing package.

IMO this is a net improvement. I'm open to other solutions but at the end of the day, we need some transparent piece of data (at least an id) to propagate from the test to the production code; I'm not aware of any other alternative.

[natenho]

ok, I can agree with that

[toddbaert]

My only current issue with this approach is cleaning up this map. It would be great if we could have some ergonomic mechanism to REMOVE things from this map, eventually. Perhaps something a user could clean-up with a defer statement in whatever scope they need.

[toddbaert]

I approve of this approach. This is my only blocker.

[toddbaert]

@warber Looks good, I have proposed one more additional ergonomic change I'd like your opinion on. Fundamentally it works the exact same way, it just changes the API a bit so that users are thinking in terms of flags for a test scope, not a provider for a test scope: warber#1

If you agree, I think we should just add a quick blurb about this in the README and then merge.

[toddbaert]

@warber after you pointed out the deprecated packaging, I moved this to openfeature/testing: 9c5de09

This is consistent with go's testing package naming, I think.