chore: use testify instead of testing

[mmorel-35]

Description

Uses testify instead of testing package so it is more concise and more readable.

[Copilot]

Pull Request Overview

This PR refactors tests to replace manual error checks and conditionals with testify’s assert and require functions for more concise and readable test code.

• Replace manual if-error checks with require/assert calls.
• Improve error messaging and consistency across test files.

Reviewed Changes

Copilot reviewed 25 out of 25 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
host/host_aix_test.go	Updated uptime test cases to use assert.Equalf.
mem/mem_test.go	Converted error checks and value comparisons to require/assert calls.
net/net_linux_test.go	Improved temporary file error messages using require.NoErrorf.
internal/common/common_test.go	Replaced manual error handling with testify assertions.
load/load_test.go	Refactored load tests to use require/assert functions.
host/host_test.go	Updated host info and uptime tests with improved assertions.
cpu/cpu_linux_test.go	Switched CPU tests to testify assertions for consistency.
host/host_linux_test.go	Converted host Linux tests to use require/assert functions.
net/net_darwin_test.go	Updated network tests with assert.NotNilf for clarity.
mem/mem_linux_test.go	Refactored Linux memory tests to use require/assert calls.
mem/mem_plan9_test.go	Converted Plan9 memory tests to testify assertions.
net/net_test.go	Updated network counters tests with assert.JSONEqf and require assertions.
cpu/cpu_test.go	Refactored CPU tests to use consistent require/assert patterns.
disk/disk_test.go	Updated disk tests to use require/assert for error and value checking.
cpu/cpu_freebsd_test.go	Converted FreeBSD CPU tests to testify assertions for better error messages.
cpu/cpu_darwin_test.go	Updated Darwin CPU tests to use require/assert and check realistic frequency.
mem/mem_darwin_test.go	Refactored Darwin memory tests to use assert.Equalf for clarity.
cpu/cpu_solaris_test.go	Switched Solaris CPU tests to rely on require/assert for error handling.
docker/docker_linux_test.go	Updated Docker tests to use require/assert for improved failure messages.
cpu/cpu_plan9_test.go	Converted Plan9 CPU tests to testify assertions to enhance test clarity.

Comments suppressed due to low confidence (1)

host/host_test.go:49

• [nitpick] Verify that the use of assert.NotZerof is intentional; if it is meant to format the error message, ensure that this function exists in the testify API. If not, consider using assert.NotZerof instead.

assert.NotZerof(t, v, "Could not get up time %v", v)

[Copilot]

Using assert.NotSamef to compare pointers checks for reference equality, which might not confirm that the VirtualMemoryStat struct is populated meaningfully. Consider using assert.NotEqualf or verifying specific struct fields to ensure the returned value is valid.

[ccoVeille]

Why testify and not gotest.tool ?

https://pkg.go.dev/gotest.tools/v3/assert

testify is very old school. We both knows it by trying to maintain testifylint.

gopsutils now uses Go 1.23 via recent go.mod changes, so I would like to suggest using gotest.tool

[shirou]

I know that testify has been around for a long time. However, it is still being updated, and most importantly, it works. it is functioning right now.

By the way, why do you think gotest.tool is the better choice? What advantages does it have?

[ccoVeille]

Hi @shirou

I know that testify has been around for a long time. However, it is still being updated, and most importantly, it works. it is functioning right now.

testify is old, known and widely used.

Unfortunately, it has many issues. A v2 was planned, but it is now a dead end.

Please read

• Document guidelines for reviewing proposed additions to the API for v2.0.0 stretchr/testify#1560 (comment)

testifylint is a way to avoid some of the issues.

Please see the mention from testify maintainer:

testifylint is a major tool that helps Testify users to avoid v1's traps. More than a v2.

Unfortunately, testifylint cannot fix code that cannot be fixed easily because testify has to be retro-compatible, it accepts any everywhere which can cause real issues.

By the way, why do you think gotest.tool is the better choice? What advantages does it have?

We had a recent discussion with @mmorel-35 about the possible alternative solutions.

We listed the following ones:

• https://github.com/alecthomas/assert

• https://github.com/gookit/goutil

• https://github.com/gotestyourself/gotest.tools

• https://github.com/shoenig/test

• https://github.com/onsi/ginkgo

We discussed about gotest.tool :

• is pretty clean
• is documented
• is maintained
• is stable
• close to testify syntax with basic checks, but with less methods/features
• provides with a CLI to migrate tests from testify to gotest.tool
• the dependencies is very limited
  , while testify comes with a lot of dependency, including go-spew that is no longer maintained.

cc @dnephin @thaJeztah who maintain gotest.tool

But, I also take a look a lib I now consider as another good candidate: https://github.com/shoenig/test made by @shoenig :

• pretty clean
• documented
• maintained
• stable
• closer to testify feature
• very limited dependencies

[shirou]

Thank you for the detailed explanation. I see, that makes sense. I also felt that testify lacks consistency in some of its functions.

I appreciate the introduction to other testing libraries as well. Having fewer dependencies is a great advantage, and the existence of a migration tool is very appealing.

For other tools I’m working on, I’ll consider using these libraries. As for gopsutil, I’ll first standardize on testify on this PR and then consider migrating to another library from there. Thank you!

[shirou]

LGTM! Thank you for the large number of changes!

[thaJeztah]

Thanks! In general, I don't think testify is necessarily bad, and I think maintenance was picked up again. Testify is used a bit more widely, which can sometimes be a benefit for contributors.

gotest.tools started as a bit of a side project to be used in the docker project; some of the existing assertion frameworks were providing too many features and some "opninionated" assertions, that looked nice, but were abstracting too much away, which in a couple of occasions resulted in tests not actually asserting what you'd think they'd do.

gotest.tools was written at the time to be much more minimal; provide the basics, with options to extent where needed. Not encouraging to hide important checks away behind the assertion library.

I should add that I'm NOT a maintainer for gotest.tools, but @dnephin is a former colleague on my team, and as a user of it, have contributed various patches to help maintain it. (Generally, code frequency in the repository should be low; mostly as a result of the project, by design, being minimal)

[ccoVeille]

Thanks @thaJeztah for your detailed reply.

I looked at the package API in detail, and I understand what you meant.

The methods are pretty basic for gotest.tool. And it's OK to be simple. I understand the design choice. It provides a good solution for a lot of simple use cases.

From my understanding, depending on my needs and on the code base I might choose it.

But, if the tests need to be more complex, and the error messages more meaningful, I think I will use @shoenig test package.

I understand the choice of @shirou to merge like this. testify was already used in the repository, well known, contributors can easily add tests by using a well known library.