| Hi Enda Phelan, Thank you for share. I replied the ML[1] and I hope that it can makes sense for you and it give a chance for you think a little more about it and who knows change your mind  Note that the CONS are good part a copy and past from the post in a blog[2] and that the book mentioned in this blog and in your email has the goal to explain the Go system and tools and this book tried compare the go test system impl X Assertions approach in another languages. The argumentations added as CONS are NOT ALL truelly 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 advantagens and incredable gains that it can offer.* For example the OpenShift, Kubernets and indeed the echo framework which was dopted for this project. Also, IHMO 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 uncesseray because it is just another way to do it, then IHMO it is accutually an easer, faster and simple way to get the tests done and mantained. Please, think a little 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 fremework 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 are NOT true for this pkg,
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 this adoption.
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
|
HI David Ffrench, Regards:
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 can check the email in this thread[1] and see for that has many strong justifications for we use testify and checking and compare the 2 pratical examples with your own eyes, mind and heart as Enda Phelan. In this case, I am heading in the wisdom in the devs who wrote OpenShift and Kubernets which has been working with this stack for too long, as echo framewrok and so many others dev which implemented OpenSource projects in this stack since it is one of the most used and popular lib in GO. Note that that OCP projects has an incredable test suite. PS.: If I be allowed to finish this task I will not spend more than 2 hours from now since Enda Phelan made a fantastic work by implement 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) c/c Austin Cunningham |