Deprecating internal/is testing library in favor of testify #198
Replies: 1 comment
-
Thanks for this message @dangerzone!
I definitely agree 😄 I talked about the reasons in here: #86. Looking at them now, I maybe should have tried harder to extend, rather than fork. It should be working as expected, most tests came from https://github.com/matryer/is.
I'm not a huge fan of large assertion frameworks where you need to learn the ins and outs of the testing framework itself. I could see us wrapping testify in an internal package to limit the API to only what we need and adding more methods as needed. But I'd need to test out testify's output again. I really like the log output that https://github.com/matryer/is has. It's nice and clean. I don't remember testify looking as nice. So TL;DR: I'm open to the idea, but I don't feel like there's currently a compelling enough reason to justify the switching cost right now. |
Beta Was this translation helpful? Give feedback.
-
Recently while working on a couple of PRs, I noticed bud has it's own testing library. I also noticed that a lot of functionality that I've come to expect from an testing library was missing, and that I'd have to implement it in the "is" package myself.
Writing our own testing library is an exercise in yak shaving, and not the goal of this project. Overall, the "is" package is ~1k lines of code that is still needs to be expanded on and maintained. And hopefully doesn't have any bugs!
I want to open the discussion here to adopt testify as the new testing library for any future changes. It has a massive list of useful assertions that can be used to save time while writing unit tests.
It also makes mocking a breeze by using the mockery tool to auto generate the mocks if one is needed.
It is battle tested and I've used it in many projects and teams. It has never failed me yet.
Beta Was this translation helpful? Give feedback.
All reactions