Ginkgo is getting in the way of properly testing our code more and more. There's big advantages to using the Go native testing (with an assertion helper like require), especially:
Migrating away from Ginkgo will be a massive undertaking, and we won't be able to do it all at once. This has to be a step-by-step migration. Fortunately, it's possible to run Ginkgo and go test in parallel, in fact, the ginkgo command invokes go test.
New test cases aded would be Go tests (unless trivial), and when doing major refactors of a struct / package, this would the time to move away from Ginkgo.
The risk here is that we'll end up in an eternally inconsistent state. Migrating the connection tests (for example) won't be fun.
Alternatively, we could embrace Go's native tools only for benchmarks and for fuzzing, while sticking with Ginkgo for tests.
Ginkgo is getting in the way of properly testing our code more and more. There's big advantages to using the Go native testing (with an assertion helper like require), especially:
Migrating away from Ginkgo will be a massive undertaking, and we won't be able to do it all at once. This has to be a step-by-step migration. Fortunately, it's possible to run Ginkgo and
go testin parallel, in fact, theginkgocommand invokesgo test.New test cases aded would be Go tests (unless trivial), and when doing major refactors of a struct / package, this would the time to move away from Ginkgo.
The risk here is that we'll end up in an eternally inconsistent state. Migrating the connection tests (for example) won't be fun.
Alternatively, we could embrace Go's native tools only for benchmarks and for fuzzing, while sticking with Ginkgo for tests.