4 ms·
Not really a framework, but I really like how golang made testing part of the language/stdlib/tooling. Is it perfect? No. Is it pretty good? Yeah. In terms of
by peter_l_downs 3y ago
Not really a framework, but I really like how golang made testing part of the language/stdlib/tooling. Is it perfect? No. Is it pretty good? Yeah.
In terms of frameworks, I am a big fan of testify. [0] Unfortunately it doesn't seem like the testify maintainers want to incorporate generics. [1] I'm going to be releasing a library soon to address that.
I'm also going to be releasing a golang+python+typescript library for doing super cheap/fast database-backed tests. In my last job I found it incredibly useful, it essentially made it ~0 cost to write tests that exercised database-related codepaths and logic, which for most business apps is everything important.
[0] https://github.com/stretchr/testify https://github.com/stretchr/testify
[1] https://github.com/stretchr/testify/issues/1147 https://github.com/stretchr/testify/issues/1147
- ivanvanderbyl 3y agoI'm curious what benefits you would gain in the testify API by adding generics?
- peter_l_downs 3y agoFinished, take a look if you're curious -- https://github.com/peterldowns/testy https://github.com/peterldowns/testy
- peter_l_downs 3y agoIt's not that large of a benefit, but when performing tests comparing two objects, I sometimes pass the wrong object type in. Most of the times this is happening, I'm refactoring existing code and updating tests as I go. It would be nice to see all the errors at compile time (and therefore in my editor's problems/quickfix view) rather than having to run the full test suite to find all the tests I forgot to update. I think it's possible to keep the implementation of testify almost (or exactly) the same, but update the type signatures of the methods to use generics, and shift-left a lot of errors to compile time. Just a nice-to-have.