Go tip contains following commmit, that inlines function with single
call bodies.
13baf4b2cd
`(*Call).On()` is the exact target for the improvement in Go repo. Due to
the inlining, assert.CallerInfo() can't not detect the file and line
number of the call to `(*Mock).On()` from `(*Call).On()`. Thus, the test
fails.
Adding the compiler directive `go:noinline` prevent this effect and make
mock package works with go tip as before.
Changes to the method signature for argumentMatcher.Matches may lead to breaking existing
external uses of that function. Introducing a new method used internally allows presenting
the error information out for internal testify functionality while not breaking other
existing uses of Matches.
This makes is possible to fail the test instead of panicing in case
that the method was called with unexpected arguments.
Fixes#489
mock: change field 'T' to be private field 'test'
mock_test: MockTestingT not using Mock anymore
commit 5b0291d47dc3a70cc6c6be3bba3c2f934a8e933e
Merge: 1f324ec 8ccf48a
Author: Dinesh Kumar <dineshkumar-cse@users.noreply.github.com>
Date: Sat Dec 30 19:55:13 2017 +0530
Merge branch 'master' into master
commit 1f324ec8cbe892a2c5364904643aa1b710121824
Author: Dinesh Kumar <dinesh.kumar@go-jek.com>
Date: Sat Dec 30 19:07:16 2017 +0530
Fixing comments: reduced test time, locking in after, unexported waitTime
- WaitUntil/After overrides each other value
- currently if channel is set that takes the priority, if not the
waitTime is used to Sleep
commit a7101ec14224918fc06532acae76418d1b4f04c5
Author: Dinesh Kumar <dinesh.kumar@go-jek.com>
Date: Fri Dec 29 13:02:14 2017 +0530
Using if else instead of switch and pulling out the commone one
commit 936f63dd689acacfd051867c5c700489caa1dbc2
Author: Dinesh Kumar <dinesh.kumar@go-jek.com>
Date: Fri Dec 29 12:41:40 2017 +0530
After - making it wait during method call
After was using call.WaitUntil(time.After(duration)),
<-time.After(duration) returns a channel with the timer immediately
started
This change fixes a race condition I discovered when a multithreaded
test in a service I work on failed under -race. The included test case
simulates that failure (concurrent mutation of a Call with invocations
on the mock). The test will fail with a data race if run under the
race detector; the new locking ensures that call fields are not
accessed without the protection of the parent mutex.
When `len(actual) > len(expected)`, this for loop would cause a panic.
Alternative to this implementation, there could be a check for
`if len(actual) != len(expected)`, but generating a meaningful message
describing that is already provided by `diff()`. So we defer to diff in
every case.
Fixes#393
Pre-diff:
```
panic: runtime error: index out of range
```
Post-diff:
```
panic:
mock: Unexpected Method Call
-----------------------------
MyFunction(string,string,string)
0: string,
1: string,
2: string
The closest call I have is:
MyFunction(string,string)
0: "mock.Anything"
1: "mock.Anything"
Provided 3 arguments, mocked for 2 arguments
```
Brandon Bodnar
Tai
Tony Jiang
gz-c
Eyal Posener
Dinesh Kumar
Ernesto Jiménez
Jonathan ES Lin
Ruben de Vries
Adam Medzinski
Joel Low
Maxim Kolganov
Peter Hsu
Dan Heller
Yimin Chen
Ernesto Jiménez
Richard Knop
Simon Mulser
Joseph Anthony Pasquale Holsten
Jonas Finnemann Jensen
Andy McCall
Tagir Magomedov
Ernesto Jiménez
Seppe Stas
Alexander Staubo
Dominic Barnes
Martin Hamrle
Konstantin Cherkasov