smart diff to testutil.GatherAndCompare

[sourikghosh]

Signed-off-by: Sourik Ghosh [email protected]
closes #996

[sourikghosh]

review @bwplotka

[kakkoyun]

Looking good.
I like to idea of using require.Equals but these are changing existing APIs. I'm reluctant to change existing public APIs.

How about adding equivalent new version of the APIs that have t *testing.T as a first parameter? and those can use require package under the hood.

[kakkoyun]

Rather than MethodNameV2, I'd prefer MethodNameWithTesting or MethodNameWithT

[sourikghosh]

Ok replacing it with MethodNameWithT
Ehh ci/circleci: go-1-16 for TestSummaryDecay failed but I run both make test and test-short locally before pushing.

[bwplotka]

Hey, thanks for this work 💪🏽

It is MUST have functionality, I miss it so much <3

But I think we need to be careful. I think we could improve this PR a bit:

• Ideally we don't force people to import extra (quite large) testify module. client_golang lib is well used library, so we need to be careful here. I think there is no strong need. Proposed alternative.
• I am not fan of extra interface (so many extra methods). I think we can remove that and add nice diff without t *testing.T - especially if we want to skip testify module import.

WDYT?

[bwplotka]

Hm.. is there a way to avoid this package? For a reason we wanted to make sure it's not used, so we are not leaking it.

Since this is not testing code, every project that imports client_golang needs to import testify.... I think we want to copy the diff function and maintain here.

See how we did that here https://github.com/efficientgo/tools/blob/main/core/pkg/testutil/testutil.go#L101

[kakkoyun]

I totally agree. I think I was a little hasty to review this, and I haven't noticed testify is not there already 🙈

[kakkoyun]

I guess because it's already a transitive dependency.

[sourikghosh]

yeah, I agree too, this makes sense
but the above diff function has a dep on
https://github.com/efficientgo/tools/blob/fe763185946be83b20da626605319733bd7f97cb/core/pkg/testutil/testutil.go#L16 which is not maintained should I transfer the module implementation over here or just simply import it.

[bwplotka]

Thanks! Sorry for complaining, but I think there is small risk with the module of choice 🤔 WDYT?

[bwplotka]

I don't want to be a pain but this module is THIS PACKAGE IS NO LONGER MAINTAINED. Not the best, since all users depending on our module will have to download it too.

I wonder if it makes sense to just copy the code for now with the required code (with test) over. Looks reasonably small. There is not benefit in depending on module that does not allow merging new changes.

Or we could find different package.

[sourikghosh]

🙃that was my question previously #998 (comment)

Ideally, I would prefer an alternative to the package but I couldn't find a good replacement. So maybe coping small piece of code and maintaining it over here ?!!!

[bwplotka]

Yea, I think copy might be better

[sourikghosh]

@bwplotka 👀

[kakkoyun]

@bwplotka Could you please have another look?

[bwplotka]

Suggested change

	// is no loger maintained.(https://github.com/pmezard/go-difflib)
	// (https://github.com/pmezard/go-difflib) is no longer maintained.

[bwplotka]

Thanks for this work, and sorry for lag. Again - please ping me on CNCF slack (:

I found quite important thing to do before we merge, WDYT?

[bwplotka]

I believe we want to make sure this is under internal path so no one can import it. Otherwise we have to care about API, Go doc comments etc.

And I don't client_golang have to be library which offers diffing 🤔

[bwplotka]

Finally!

Thanks for your hard work 💪🏽

LGTM