How to assert equals on structs with a time field

[MrNemo64]

I have this struct

type DBJob struct {
    Id          int64     `db:"id"`
    Name        string    `db:"name"`
    Data        string    `db:"data"`
    State       JobState  `db:"state"`
    CreatedAt   time.Time `db:"created_at"`
    AvailableAt time.Time `db:"available_at"`
}

And my tests fail because of the CreatedAt and AvailableAt. Let's set an example:

In a test if I insert into the DB an instance and recover it, there is a negligible loss of precision but since it's not the exact same time the test fails. In testify there is assert.WithinDuration but I can't use this with structs. I've looked at the testify repository and seen several issues mentioning this like #1388 and #984 but none are closed so is this not possible? To show what I mean

func TestTimes(t *testing.T) {
    // container has a testcontainers postgres container and a *sqlx.DB instance
    container := prepareForTestCase()
    t.Cleanup(func() {
        if err := container.Shutdown(); err != nil {
            t.Errorf("Error shuting down test container: %v", err)
        }
    })

    expected := jobs.DBJob{
        Id:          1,
        Name:        "Test job",
        Data:        "{}",
        State:       jobs.JobStatePending,
        AvailableAt: time.Now().UTC(),
        CreatedAt:   time.Now().UTC(),
    }
    if _, err := container.DB.NamedExec(
        `INSERT INTO jobs(id, name, data, state, created_at, available_at)
        VALUES (:id, :name, :data, :state, :created_at, :available_at);`,
        expected); err != nil {
        t.Errorf("Error inserting job %v: %v", expected, err)
    }

    var found jobs.DBJob
    row := container.DB.QueryRowx(`SELECT * FROM jobs WHERE id = 1;`)
    row.StructScan(&found)

    assert.Equal(t, expected, found, "The jobs do not match") // <-- Fails
}

This equals fails

expected: jobs.DBJob{Id:1, Name:"Test job", Data:"{}", State:"pending", CreatedAt:time.Date(2024, time.June, 17, 18, 59, 34, 455519734, time.UTC), AvailableAt:time.Date(2024, time.June, 17, 18, 59, 34, 455519673, time.UTC)}
actual  : jobs.DBJob{Id:1, Name:"Test job", Data:"{}", State:"pending", CreatedAt:time.Date(2024, time.June, 17, 18, 59, 34, 455520000, time.UTC), AvailableAt:time.Date(2024, time.June, 17, 18, 59, 34, 455520000, time.UTC)}

The time is the same but the millisecconds which seems to be a loss of precition. How can I assert that two instances of this struct are equals whithing like 500ms?

[brackendawson]

My recommendation for such structs, where you do not actually want some fields to be Equal is to write a test helper function to define what you consider to be "equal":

func assertDBJobCloseEnough(t *testing.T, expected, actual jobs.DBJob) bool {
    t.Helper()
    return assert.Equalf(t, expected.Id, actual.Id, "Expected Id=%d but got Id=%d", expected.Id, actual.Id)
        & assert.Equalf(t, expected.Name, actual.Name, "Expected Name=%s but got Name=%s", expected.Name, actual.Name)
        & assert.Equalf(t, expected.Data, actual.Data, "Expected Data=%s but got Data=%s", expected.Data, actual.Data)
        & assert.Equalf(t, expected.State, actual.State, "Expected State=%v but got State=%v", expected.State, actual.State)
        & assert.WithinDurationf(t, expected.AvailableAt, actual.AvailableAt, time.Millisecond*500, "Expected AvailableAt=%v±0.5s but got AvailableAt=%v", expected.AvailableAt, actual.AvailableAt)
        & assert.WithinDurationf(t, expected.CreatedAt, actual.CreatedAt, time.Millisecond*500, "Expected CreatedAt=%v±0.5s but got CreatedAt=%v", expected.CreatedAt, actual.CreatedAt)
}

Another option is to fully constrain the test environment's inputs, including time, so that you can fully test for state. This might mean making an interface to time that you can mock, or designing your internal APIs differently.

[MrNemo64]

That's a good option I'll try but now another question I have, what if I want to compare two []jobs.DBJobs? I'd manually first have to check the lengths and if they match test each position, and if they don't match manually search for the missing items/extra?

[brackendawson]

Doing the ElementsMatch algorithm with this "SortOfEqual" thing sounds challenging. Potentially a given element in listA might match multiple elemenrs in listB, some closer than others. Pairing up the elements sub-optimally might prevent it matching, and possibly a differently shuffled version of the lists would match.

eg with tolerance of 0.5 this arrangement fails:

listA    listB
  0.4 ~= 0.4
  0.1 ~! 0.7

but this arrangement passes:

listA    listB
  0.1 ~= 0.4
  0.4 ~= 0.7

This sort of thing is why I really prefer not using "SortOfEqual" assertions, there are so many problems.

[MrNemo64]

I can see what you mean. In my case, I also have the id and all that so I highly doubt that will be an issue, but something to keep in mind nonetheless