Hi [~endaphelan],
Thank you for share. I replied the ML[1] and I hope that it can make sense for you and our teammates and it gives a chance for you think a little more about it an reconsideration and who knows may change your mind :-)
Note that the CONS shared in the thread are a good part came from the blog[2]. *The argumentations added as CONS in the thread are NOT ALL truly valid for "testify/assert"* which is one the most popular and used pkg in GO which is the testify/assert as you can check here[3].
*See that the biggest part of the OpenSource projects in this stack are using testify/assert because of all advantages and incredible gains that it can offer. For example the OpenShift, Kubernets and indeed the echo framework which was adopted for this project.* Also, IMHO we should follow up the OpenShift project which is one of the best examples for this stack and it is made by us, RedHat.
Since you added as CONS that it is unnecessary because it is just another way to do it, then IHMO it is actually an easier, faster and simple way to get the tests done and maintained. Please, I'd like to ask you think a little more over it: If it is not good at all, why OpenShift and Kubernets which are examples/standards for the stack are using it? Why it is the most popular and used GO lib? Why echo is using it and describing in its docs how to do the test with? Is the implementation of the framework adopted by us really not follow up the good practices as these others all big OpenSource projects?
* Following one example of the CONS added that is NOT true for this pkg,
bq. Tests stop executing after the first assert fails - masking patterns of failure
* Following the test made locally in order to show that it is NOT the behaviour faced with
{code:java}
camilamacedo@Camilas-MacBook-Pro ~/go/src/github.com/aerogear/mobile-security-service (AEROGEAR-8583) $ make test
Running tests:
GOCACHE=off go test -cover \
github.com/aerogear/mobile-security-service/pkg/config github.com/aerogear/mobile-security-service/pkg/db github.com/aerogear/mobile-security-service/pkg/httperrors github.com/aerogear/mobile-security-service/pkg/web/apps github.com/aerogear/mobile-security-service/pkg/web/router
--- FAIL: TestGetEnv_OverrideValues (0.00s)
config_test.go:77:
Error Trace: config_test.go:77
Error: Expected nil, but got: "json"
Test: TestGetEnv_OverrideValues
FAIL
coverage: 100.0% of statements
FAIL github.com/aerogear/mobile-security-service/pkg/config 0.060s
? github.com/aerogear/mobile-security-service/pkg/db [no test files]
ok github.com/aerogear/mobile-security-service/pkg/httperrors 0.035s coverage: 96.3% of statements
ok github.com/aerogear/mobile-security-service/pkg/web/apps 0.033s coverage: 77.2% of statements
? github.com/aerogear/mobile-security-service/pkg/web/router [no test files]
make: *** [test-unit] Error 1
{code}
HI [~dffrench],
Regards:
bq. Just getting to this now. I would agree, unless there is a strong need or justification for introducing testify, we should be heeding the wisdom of developers that have worked on the existing Mobile Services.
I hope that you and [~endaphelan] can check the email in this thread[1] and see that has many strong justifications for we use testify and see it with your own eyes, mind and heart by comparing the 2 practical examples which were added there as [~endaphelan] that has many strong justifications for we use the pkg . :-)
In this case, I am heading in the wisdom of the devs who wrote OpenShift[6] and Kubernets[5] which has been working with this stack for too long, as echo framework[4] and so many others devs which has been implementing OpenSource projects with GO since it is one of the most popular lib. Note that that OCP project has an incredible test suite.
PS.: If I am will be allowed to finish this task tas then I will not spend more than 2 hours from now to finish it since * [~endaphelan] made a fantastic work by implementing many tests and this project still too small. *
[1] - https://groups.google.com/d/msgid/aerogear/f6d257f7-3668-48ee-8d8e-0243aac29277%40googlegroups.com?utm_medium=email&utm_source=footer
[2] - https://blog.alexellis.io/golang-writing-unit-tests/
[3] - https://godoc.org/ (atached image)
[4] - https://echo.labstack.com/guide/testing
[5] -https://github.com/search?q=org%3Akubernetes+%22github.com%2Fstretchr%2Ftestify%2Fassert%22&type=Code
[6] - https://github.com/search?q=org%3Aopenshift+%22github.com%2Fstretchr%2Ftestify%2Fassert%22&type=Code
c/c [~austincunningham] |
|
