A Go linter that checks for common mistakes and enforces best practices when using the testify testing framework.
testifylint is a static analysis tool for Go that identifies problematic patterns and enforces consistent, readable, and bug-free usage of the popular testify testing framework. It helps maintain test quality by catching ambiguous API usage, simplifying code, and preventing common errors that can lead to flaky or misleading tests.
Go developers who use the testify framework for writing tests and want to improve test reliability and maintainability. It is particularly useful for teams enforcing coding standards in test suites to avoid common pitfalls.
Developers choose testifylint because it specifically targets testify's ambiguous APIs and common mistakes, offering automated fixes for many issues. It enforces best practices that reduce bugs and improve test clarity, which is not covered by generic linters.
The Golang linter that checks usage of github.com/stretchr/testify.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Detects over 25 problematic patterns, from boolean comparisons to suite misuse, covering common testify pitfalls that generic linters miss.
Offers autofix for many checkers like bool-compare and expected-actual, simplifying refactoring and enforcing best practices with minimal manual effort.
Configurable via golangci-lint, making it easy to add to existing CI/CD pipelines for Go projects, though autofix is currently unavailable in that setup.
Enforces assertions that improve test failure readability, such as correcting swapped expected/actual arguments and promoting proper error handling APIs.
Some checkers, like error-is-as and formatter, only offer partial autofix, and fixing with golangci-lint is unavailable due to a known integration issue.
Does not automatically handle sequential fixes, requiring multiple linting passes to resolve all issues, which can complicate the refactoring workflow.
Designed specifically for testify v1 APIs, so it may become less relevant if testify v2 introduces breaking changes, though v2 is not imminent.