In the general case, all testify assertions are doing under the hood is
call t.Errorf (see here
<https://github.com/stretchr/testify/blob/f654a9112bbeac49ca2cd45bfbe11533c4666cf8/assert/assertions.go#L262>).
If you're calling the "FailNow" set of functions that's followed by
t.FailNow, which ends the test early. As others have stated, that's no
different than you calling those methods on testing.T, directly.
What led you to believe that using testify/assert is against Go best
practices?
On Friday, October 2, 2020 at 7:27:28 AM UTC-4 vlad...@varank.in wrote:
> Hey,
>
> I don't think the statement about "assert going against the best practices
> in go unit tests" stands against the reality, sorry. One definitely doesn't
> have to use a separate assertion package to write unit-tests in Go,
> comparing to some other programming languages. But there is really no much
> difference between using an assertion of t.Fail-ing manually.
>
> In our project, we use testify assertions (only for statistics: our
> monorepo is ~400K lines of Go code with every package covered with
> unit-tests) and it works great just by reducing the total number of lines
> in our test files and making them much more manageable (we have unit-tests
> files that over years has grown over 3K+ LOC now).
>
> Depending on the interface, we usually create a separate "controlled"
> implementation, that we use in unit-tests. E.g. if we implemented a
> DataStore, we would have an in-memory implementation with additional
> Setter-methods, that accepted an optional "hook", that allowed us to return
> an error.
>
> We don't use "testify/mock" because we aren't interested in verifying the
> calls or the arguments that were passed to the mock. Usually, it's easier
> to write a fake implementation. I.e. our testing implementations are more
> "fakes" than "mocks".
>
> One neat thing about that approach is that testing implementation doesn't
> always have to expose lots of knobs. If one unit-test needs to tune the
> behaviour, you can always stub the dependency right in-place and use it for
> this single test only. E.g.
>
> type testDataStore struct {
> callFooFunc() error
> }
>
> func (s *testDataStore) Foo() error {
> return s.callFooFunc()
> }
>
> func TestSomething(t *testing.T) {
> ds := &testDataStore {
> callFooFunc: func() error {
> return fmt.Errorf("a very specific error that make sence to
> test against in this test only")
> }
> }
> // ยทยทยท
> }
>
> Hope that makes sense.
>
> On Thursday, October 1, 2020 at 6:26:19 PM UTC+2 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/9d20e10b-e6a7-45d1-ad62-b7883a844b6fn%40googlegroups.com.
