Add function for supporting JSON equality checks using byte slices

[GCrispino]

Summary

This PR adds a new function into the assert package, JSONEqBytes, that does the same as JSONEq, but by receiving []byte values as parameter instead of string ones.

Changes

assert/assertions.go:
The implementation of JSONEqBytes is pretty much what was in JSONEq, but having it receive []byte values and then not needing to convert these values to []byte when calling json.Unmarshal inside it.

Then, the implementation of JSONEq was changed such that it just calls JSONEqBytes by converting its original arguments to []byte values (which it already did when calling json.Unmarshal)

assert/assertions_test.go:
Tests for JSONEqBytes function were replicated from the tests from JSONEq.

Motivation

It is common in Go to store JSON text in []byte variables instead of string values, so having a function that allows to receive these values when doing JSON-equality checks without having to cast them to string can be useful.

Maybe not as important, it would also avoid unnecessary []byte-to-string conversions, which could add up when dealing with big JSON payloads.

Example of usage:

package main

import (
    "fmt"
    "testing"
    "github.com/stretchr/testify/assert"
    "github.com/stretchr/testify/require"
)


func TestJSONFiles(t *testing.T) {
    actualFile := "/path/to/file.json"
    byteValue, err := ioutil.ReadAll(jsonFile)
    require.NoError(t, err)

    expectedContentsFile := "/path/to/expected.json"
    byteValue, err = ioutil.ReadAll(jsonFile)
    require.NoError(t, err)

    assert.JSONEqBytes(t, expected, byteValue)
}

[hendrywiranto]

Hi !
this one is great but I think currently maintainers are more focused in fixing bugs rather than expanding the API interface.
Let's wait their response

[brackendawson]

This is a good implementation.

I have questions about whether JSONEq should have ever been added. My preference would always be your API should yield stably formatted output. If JSONEq should have been added then it should have always accepted a []byte rather than a string. I'm not going to merge this without input from other maintainers, any thoughts @dolmen?

It would be useful to see if there is a real world example where the string is prohibitively expensive.

[brackendawson]

@GCrispino can you re-base to run the latest version of the tests.

[brackendawson]

I note that YAMLEq also accepts a string, that's an even more problematic assertion.

[GCrispino]

@brackendawson rebased my branch against master and re ran go generate and go fmt 👍🏼

[brackendawson]

Still approve, as per my previous comments.

[GCrispino]

@brackendawson thanks! Is there something else I should do, or are you only expecting review from another maintainer?

[brackendawson]

@brackendawson thanks! Is there something else I should do, or are you only expecting review from another maintainer?

Nothing else needed from you at this time, just wait for another maintainer to opine.