Open junedev opened 2 years ago
As much as I love (d) testify at work, as much am I opposed using it, as long it isn't the one-stop-shop solution in the community.
As long as there are competitors that are equally used in the wild, using a certain framework here, might cause confusion for students that (have to) use something else at work.
If we stick to gos provided testing "library" we lower the burden, as it is more likely that a coworker can "translate".
I checked what some prominent Go projects are doing, I'll leave my findings here for reference:
I'm also in favor of using testify. Right now there are a couple of problems with our tests that testify (or a similar library) could help us solve:
Teaching something that is not "standard" is always a concern we must have in mind, but I think I'm ok with it in this case, especially because assertion libraries are just functions at its core. They are not frameworks and they don't force on you a way to write tests at a high level. You are still using standard features like functions starting with Test
that take a *testing.T
from the standard library and you still use go test
. And there's nothing forcing us to use assertion functions if we see they don't help us in a particular case - they are there to help, we can just not use them if they don't. So I don't see assertion libraries as forcing a particular way of testing that is not valuable for the student, I believe a student can still get a pretty good idea of how testing works in Go even if we use an assertion library.
However, I agree there might be a balance to be made here, on one hand, we must be careful to not overuse an assertion library, but on the other hand, we must use it when it makes sense. I don't know exactly where that line lies, but I'd say we should just try and we'll figure that out along the way.
On the argument of popularity, I also think testify is popular enough for that to not be a problem.
at least for small texts I still think that cmp is simpler and as beauty as testify if you do a small trick. I did some tests comparing assert.Equal(a, b)
, cmp.Diff(a, b)
and cmp.Diff(strings.Fields(a), strings.Fields(b))
and turns out that I prefer cmp.Diff
sometimes and cmp.Diff
using strings.Fields
for most cases...
This can of worms was opened up in Slack discussion and is something that has been on my mind for a while so I want to use this issue to follow up on the discussion.
Question: Do we want to use some external package like testify as assertion library in all the exercise tests?
The test runner can handle external dependencies by "baking them in" when creating the docker image so technically, this is feasible.
Here my thoughts on the matter:
assert
andrequire
for exactly this use case.While I personally think, using testify would be the right move, the following things are currently holding me back a bit from fully pushing for it:
As @andrerfcsantos mentioned somewhere, there is also the option of only using cmp but imo that would bring the drawbacks of having an external dependency but would not address the general issue of test readability.
Another alternative would be to only use testify in some exercises but I would prefer to keep tests consistently easy to read for students.