As for mocking dependencies: in my experience, the best strategy is often not to.
It is a good idea to avoid depending on services or resources external to the test, such as other production services. However, in my experience you'll get much better test fidelity — you'll find more real bugs, and spend less time fixing erroneous test assumptions — if you have the test use its own hermetic instance of the real dependency. On Thursday, October 1, 2020 at 12:26:19 PM UTC-4 krish...@gmail.com wrote: > We are working on a full scale production app with go backend. > > For unit tests, we need to mock the dependent interfaces either by > creating our own mock implementation of the interface or by using third > party packages like *testify/mocks.* > > If we use testify, there will be a tendency for the developers to use *assert > *statements which is against the best practices in go unit tests. (We use > t.Fail instead of asserts) > > If we create manual mocks, we will end up creating two implementations for > each interface, one for the program and another for the unit testing. Also > we cannot test by mocking with different outputs from the dependencies. > example if the dependency return an error. > > Please suggest which the right approach here. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2b1affd7-1599-4943-8419-d9718f17780fn%40googlegroups.com.
