Hi all, As we are currently at the stage of implementing key components in the Synapse Go project, I believe it's worthwhile to consider establishing a proper testing methodology from the outset. This approach will make it significantly easier for future developers to contribute, maintain, and extend the codebase with confidence, reducing the risk of regressions and improving overall code quality.
To inform this discussion, I conducted some research on mainstream Golang testing packages and frameworks. Here's a summary of the popular alternatives I looked into: 1) The built-in `testing <https://pkg.go.dev/testing>` package: Go's standard library offering, which provides basic test functions and is lightweight with no external dependencies. 2) Testify <https://github.com/stretchr/testify>: A popular extension to the built-in testing package, adding assertions, mocks, and test suites for more expressive tests. 3) Ginkgo <https://github.com/onsi/ginkgo> paired with Gomega <https://github.com/onsi/gomega>: A BDD-style framework that allows for descriptive, hierarchical test structures, making complex test suites easier to read and organize. 4) GoConvey <https://github.com/smartystreets/goconvey>: Focuses on web-based test reporting and BDD-like assertions, with auto-watching for test runs. 5) Httpexpect <https://github.com/gavv/httpexpect>: Specialized for HTTP API testing, providing fluent assertions for responses. 6) Goblin <https://github.com/franela/goblin>: A simple, Mocha <https://mochajs.org/>-inspired BDD framework with a focus on readability. 7) Go-testdeep <https://github.com/maxatome/go-testdeep>: Emphasizes deep comparison assertions for complex data structures. During my research, I noted that Ginkgo <https://github.com/onsi/ginkgo> and Gomega <https://github.com/onsi/gomega> are particularly popular in large-scale projects. For instance, they are used in major CNCF projects like Kubernetes <https://github.com/kubernetes/kubernetes> for end-to-end testing, where the BDD style helps in writing tests that read like specifications, potentially making them easier to understand and maintain for collaborative environments. However, after evaluating these options, I think sticking with Testify <https://github.com/stretchr/testify> which is the framework we're currently using makes the most sense. Testify <https://github.com/stretchr/testify> builds directly on Go's built-in testing package, offering a familiar API with essential features like require/assert, suite support, and mocking without introducing unnecessary complexity or a steep learning curve. It's lightweight, has excellent community support, and is widely adopted in the Go ecosystem, which means most contributors will already be comfortable with it. Unlike more opinionated BDD frameworks, it doesn't enforce a specific style, allowing flexibility as the project grows. This is why I believe Testify <https://github.com/stretchr/testify> is a good fit for our project: it aligns with our current setup, promotes consistency, and provides just enough enhancements to make testing efficient without overcomplicating things for a project like Synapse Go. I'd love to hear your feedback on this choice - do you agree with continuing with Testify <https://github.com/stretchr/testify> or do you have preferences for one of the alternatives? Your suggestions are welcome! Best regards, *Thisara Rathnayaka* Undergraduate Student | Computer Science & Engineering University of Moratuwa 📞 +94-77-104-6532 LinkedIn <http://www.linkedin.com/in/weerakoon-thisara-rathnayaka-881826177> | GitHub <https://github.com/ThisaraWeerakoon> | Blog <https://medium.com/@thisara.weerakoon2001>
