This repository has been archived by the owner on Jul 11, 2023. It is now read-only.
Use Go std testing library for unit tests #1704
Labels
Comments
codefromthecrypt
pushed a commit
to tetratelabs/func-e
that referenced
this issue
Mar 24, 2021
To call gomega indirect would be putting things lightly. A combination of an indirect testing library and long-running tests are a recipe for frustration. I've begun a process to remove gomega with a couple tests that I had been looking at. While the rationale is fairly straightforward, the following issue captures a lot of it nicely: openservicemesh/osm#1704 If doing this is ok, I don't mind finishing the e2e suite including improving the docs. See #127 Signed-off-by: Adrian Cole <adrian@tetrate.io>
codefromthecrypt
pushed a commit
to tetratelabs/func-e
that referenced
this issue
Mar 26, 2021
To call gomega indirect would be putting things lightly. A combination of an indirect testing library and long-running tests are a recipe for frustration. I've begun a process to remove gomega with a couple tests that I had been looking at. While the rationale is fairly straightforward, the following issue captures a lot of it nicely: openservicemesh/osm#1704 If doing this is ok, I don't mind finishing the e2e suite including improving the docs. See #127 Signed-off-by: Adrian Cole <adrian@tetrate.io>
codefromthecrypt
pushed a commit
to tetratelabs/func-e
that referenced
this issue
Mar 26, 2021
To call gomega indirect would be putting things lightly. A combination of an indirect testing library and long-running tests are a recipe for frustration. I've begun a process to remove gomega with a couple tests that I had been looking at. While the rationale is fairly straightforward, the following issue captures a lot of it nicely: openservicemesh/osm#1704 If doing this is ok, I don't mind finishing the e2e suite including improving the docs. See #127 Signed-off-by: Adrian Cole <adrian@tetrate.io>
mathetake
pushed a commit
to tetratelabs/func-e
that referenced
this issue
Mar 31, 2021
To call ginkgo,gomega indirect would be putting things lightly. A combination of an indirect testing library and long-running tests are a recipe for frustration. I've begun a process to remove ginkgo,gomega with a couple tests that I had been looking at. See #127 ## Some benefits * Before, we both had tests using normal testing,testify and also ginkgo,gomega. Now we only have way to write tests: testing,testify. * testing,testify are more popular and easier to learn than ginkgo,gomega. testing is the standard library described in all golang books. testify is a simple assertion library 10x more popular than gomega in terms of star count. Neither require learning BDD concepts. * Before, our running of e2e tests was significantly different than our other non-gingko tests in the same project. It literally required compilation of a platform-specific binary named 'e2e', adding a lot of complexity to CI and local setup. * Before, individual tests cannot be executed via normal means, such as Goland. Instead, you have to run the suite file. Now, you can execute and more importantly debug individual tests instead of via a suite wrapper. * Before, writing tests not only required understanding of the subject, but also the ginkgo runtime. Otherwise, statements like `var _ = Describe("getenvoy extension init", func() {` seem pure magic. * Before, the nature of test execution required a combination of understanding the go platform and also ginkgo * Before, updating Ginkgo/gomega would skew the dependency tree, due to their dependencies on two protobuf libraries. Now, the test runtime does not interfere with main code. * Before, the same test took more lines of code to achieve the same table test. Less code is less to maintain. * Some other notes about migration off are captured in this issue openservicemesh/osm#1704 ## Notable differences Gomega had a different way of logging. For example instead of using a logging library, it would use statements like this: `By("changing to the output directory")` which translate into output `STEP: changing to the output directory`. This is mainly to satisfy BDD idioms and is meant to be interpreted amongst the many lines of normal log output. For cases where the points inside the test should be logged, we should use normal logging instead. However, I don't recommend making log statements unless they are meaningful and clarify progress. Also, those not used to it will notice use of normal go `defer` commands instead of the before/after test hooks used in tools like gomega. This can take getting used to, but it is also the same as normal go code, so shouldn't be time lost. There are some cases where multiple tear-down steps are needed and those steps are more visible now. That's not necessarily bad because these typically are also the most complex tests and have a lot going on. Seeing the various setup requirements shows problem areas that help knowing when debugging. Signed-off-by: Adrian Cole <adrian@tetrate.io>
|
FYI I felt your issue helpful, so thanks for capturing rationale. I also built more rationale here in case it is useful to you. cheers tetratelabs/func-e#130 |
15 tasks
snehachhabria
added a commit
to snehachhabria/osm
that referenced
this issue
Aug 31, 2021
Update the testing tests to use go testing and improve coverage to 80% Part of openservicemesh#1704 and # 1489 Signed-off-by: Sneha Chhabria <snchh@microsoft.com>
snehachhabria
added a commit
to snehachhabria/osm
that referenced
this issue
Aug 31, 2021
Update the existing tests to use go testing framework and improve coverage to 80% Part of openservicemesh#1704 and # 1489 Signed-off-by: Sneha Chhabria <snchh@microsoft.com>
snehachhabria
added a commit
to snehachhabria/osm
that referenced
this issue
Aug 31, 2021
Update the existing tests to use go testing framework and improve coverage to 80% Part of openservicemesh#1704 and # 1489 Signed-off-by: Sneha Chhabria <snchh@microsoft.com>
snehachhabria
added a commit
to snehachhabria/osm
that referenced
this issue
Aug 31, 2021
Update the existing tests to use go testing framework and improve coverage to 80% Part of openservicemesh#1704 and # 1489 Signed-off-by: Sneha Chhabria <snchh@microsoft.com>
snehachhabria
added a commit
to snehachhabria/osm
that referenced
this issue
Aug 31, 2021
Update the existing tests to use go testing framework and improve coverage to 80% Part of openservicemesh#1704 and # 1489 Signed-off-by: Sneha Chhabria <snchh@microsoft.com>
|
OSM has been using Go std library as the default for unit testing for some time, closing this issue as all new code has been using the same. We can reopen another issue when we need to clean up old test code. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Background:
Historically, we leveraged Ginkgo, a BDD style testing framework, and Gomega, an assertion/matcher library best paired with Gingko, for unit tests but after using it for a while we discovered:
Proposal:
Let's move back to using the Go standard testing package for unit tests in this repository. Over time, we'll convert the Gingko tests back to using the testing package but that is not a high priority any time soon. We can and should leverage Gingko/Gomega for e2e tests like Kubernetes and other projects do.
Open Questions:
Assertion/matcher libraries like Gomega and Testify help make it easier to write tests and more cleanly assert equality, replacing if/else statements. Testify is a toolkit that offers more tools outside of just their assert package. We use both Gomega and Testify in our project today. A question for the maintainers/community: should we continue using both assertion type libraries or move toward one or none?
When thinking about this it might be helpful to think about what is important to you. When discussing with the team, a things that bubbled up as important:
What are other factors that are important when deciding which assertion library to pick?
The text was updated successfully, but these errors were encountered: