Improve how we use git in eext and improve the code's testing facilities. #152
Conversation
mkisielewski-arista
force-pushed
the
mkisielewski-improve-git-shenanigans
branch
from
4a3212b to
7f5bb57
Compare
impl/create_srpm_from_git_test.go
Outdated
| "code.arista.io/eos/tools/eext/util" | ||
| "github.com/spf13/viper" | ||
| "github.com/stretchr/testify/require" | ||
| //"code.arista.io/eos/tools/eext/executor/mocked_executor" |
There was a problem hiding this comment.
Comment can be removed
There was a problem hiding this comment.
Good catch, sorry :D
| // MockedExecutor returns the Response objects for each of the MockedExecutor | ||
| // calls. The responses are consumed in the natural order, meaning [0] is the | ||
| // first one to be returned. | ||
| Responses []Response |
There was a problem hiding this comment.
Should we consider making this a struct of Call and Response.
type MockedExecutor struct {
MockedEntries []struct{
Response Response
Call RecordedCall
}
}
Currently the onus of maintaining the order of Response is on the dev, and I feel the mapping might get messier with longer Response slices.
There was a problem hiding this comment.
It took me a while, but I think I get what you mean now...
This is unpaired in my branch, because it's not guaranteed that the actual call that was made corresponds to given Response.
Example:
The dev writes tests for function foobar that is supposed to call add 2 times. Once with (1, 1), and second time with (2, 2). So the dev creates two Response objects - one that returns 2 and one that returns 4.
It turns out that somebody patched foobar and now it calls add 4 times - (1,1), (3,5), (2,2), and (5,0). This means that there are 4 recorded calls, and the test author expected only 2.
My approach is somewhat standard and follows approach from python:
https://docs.python.org/3/library/unittest.mock.html
In one of the examples they give this:
mock.side_effect = [5, 4, 3, 2, 1]
mock(), mock(), mock()
(5, 4, 3)5 responses, and only 3 RecordedCalls.
I'm changing the name of Calls to RecordedCalls to hopefully make it less misleading.
| if err != nil { | ||
| t.Fatal(err) | ||
| mex := executor.MockedExecutor{ | ||
| Responses: []executor.Response{executor.NewResponse(0, "libpcap-1.10.1", nil)}, |
There was a problem hiding this comment.
This Response is the mocked output for the call
rpmName, err := executor.Output("rpmspec", cmd...)
within the getRpmNameFromSpecFile().
But that isn't evident here.
Furthermore a reason to have a struct of Call and Response for easier readability.
executor/dryrun_executor.go
Outdated
| @@ -15,7 +15,7 @@ type DryRunExecutor struct { | |||
| // extra abstractions feel unnecessary. | |||
|
|
|||
| // human friendly description of what an invocation would do | |||
| invocations []string | |||
| Invocations []string | |||
There was a problem hiding this comment.
We aren't using this member outside this file. Do we need to export it?
There was a problem hiding this comment.
At this moment nope. Good idea. Let me "unexport" it.
The purpose of the function was missing, and the comment grammar implied that only the pull is being done.
There was a lot of boiler plate that was hard to follow, so this patch introduces a simple list of git commands to run. It should also yield potentially better error messages in case of a failure.
mkisielewski-arista
force-pushed
the
mkisielewski-improve-git-shenanigans
branch
from
5b6db92 to
c8221bb
Compare
|
I've updated the branch with improvements suggested by Manith |
Previously the tests for code that sourced packages with git was downloading actual repositories. This PR rearranges the code a bit to make it more testable, introduces a simple executor mock, and uses it, making the whole process more contained.
It also has a small fix (97b67a2) that properly handles commits used as revisions. The new tests also cover this logic path.