v3(tests): use testify for assertion

[trim21]

Please provide enough information so that others can review your pull request:
close #2035

Explain the details for making this change. What existing problem does the pull request solve?

replace all utils.AssertEqual with testify/require

[trim21]

I'm not very familiar with our PR merging workflow, can I just merge it or I should wait another maintainer to do it 🤔 @efectn

[ReneWerner87]

Just wait for the maintainers. You can merge little things like dependencies updates, documentation or test update, but should wait for big decisions.

[ReneWerner87]

And best never merge your own code without feedback from others, otherwise no one can give feedback.

[efectn]

Testify is OK to me since it has more detailed output and better methods.

[ReneWerner87]

Just don't know if we should do that
The idea of fenny then, was to have as little dependence as possible

Hope in version 3 we can follow this idea as good as possible, so if it is not absolutely necessary, we should not make ourselves dependent

[efectn]

I think v3 has less deps than v2 at the moment. We can also write custom extractor instead of using msgp i suppose.

https://github.com/gofiber/fiber/blob/v3-beta/go.mod

[trim21]

I want say that vendoring go package in internal/ is not a good idea .....

[ReneWerner87]

Yes I agree, that's why I have already allowed some dependencies

My only question is if we got along with our native test functions so far, do we really need an extra package?
Should only be questioned so we have as few dependencies as possible

[trim21]

that dependent on why we need to "have as little dependence as possible" I think 🤔

To make user download less code or something else?

[ReneWerner87]

One dependency quickly becomes several, when the next developer wants to write his test with other libs we suddenly have a lot of dependencies.

But if we don't allow these from the beginning and extend our internal test function a bit, we would be free from these decisions.

I'll look at the code later which assertion is not possible with our internal function

[trim21]

when the next developer wants to write his test with other libs we suddenly have a lot of dependencies.

I think we can have some code style guide about this...

I'll look at the code later which assertion is not possible with our internal function

there isn't, all assertions are possible in our internal function, I just use some gofmt rewrite rule to convert them (and some manually update）.

#2035 (comment)

I think that it's better to use a popular assertion libaray than writing many our own assertion (or use a AssertEqual in many style) for maintaining