-
Notifications
You must be signed in to change notification settings - Fork 19
Add file assertion #147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add file assertion #147
Changes from 2 commits
781486a
b282aa0
fe89129
2a616dc
5b1bcbb
adeb098
571c5e4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -48,16 +48,16 @@ func TestTextMatcher_ValidateFails(t *testing.T) { | |
|
||
func TestEqualMatcher_Validate(t *testing.T) { | ||
m := EqualMatcher{} | ||
got := m.Match(1, 1) | ||
got := m.Match(2, 2) | ||
assert.True(t, got.Success) | ||
} | ||
|
||
func TestEqualMatcher_ValidateFails(t *testing.T) { | ||
m := EqualMatcher{} | ||
got := m.Match(1, 0) | ||
got := m.Match(2, 3) | ||
assert.False(t, got.Success) | ||
assert.Contains(t, got.Diff, "+0") | ||
assert.Contains(t, got.Diff, "-1") | ||
assert.Contains(t, got.Diff, "+3") | ||
assert.Contains(t, got.Diff, "-2") | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I noticed that there was always a "-1" in the diff output because it tells the user how many lines changed, so this makes the test a tiny bit less brittle. |
||
} | ||
|
||
func TestContainsMatcher_Match(t *testing.T) { | ||
|
@@ -183,3 +183,19 @@ another` | |
assert.False(t, r.Success) | ||
assert.Equal(t, diff, r.Diff) | ||
} | ||
|
||
func TestFileMatcher_Validate(t *testing.T) { | ||
m := FileMatcher{} | ||
got := m.Match("zoom", "zoom.txt") | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm okay with reading directly from the filesystem here, there's not really a good way to mock Another direction that could be taken is removing the actual code needing to be tested and placing it in a private helper function. For example, it wouldn't be stretch to write a helper function that could be used in both There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One thing @SimonBaeumer if we take the approach from reading from the FS should we designate a folder to do this? Or a temp file could be created and then used/removed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought about the temp file approach but I wanted input since that didn't feel great either. Ordinarily I'd probably accept a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, the only other thing I can really think of is to type TestingMocking struct {
readFile func(filePath string) ([]byte, error)
} You could then setup func (m FileMatcher) Match(got interface{}, expected interface{}) MatcherResult {
buf, err := m.readFile(expected.(string))
// rest goes here This would allow us to mock readFile. Again I think this may be too robust. I think I'll defer @SimonBaeumer on this as I don't really have preference. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good call, I'll try that out and see how it ends up. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hey Together, The downside of mocking is in general that it gets very complex and often takes a lot of effort to maintain. Go ignores directories starting with underscores, like
The testing framework of go will execute all tests with the working directory pointing to the currently executed file, so it is easy to access the testdata. Mocking: Another option like @dylanhitt mentioned is to use dependency injection. That means that we inject (normally as input parameters in the constructor or functions) dependencies on other structs (or classes). Original implementation, i.e. in
In your test
Nevertheless, I am totally happy with both approaches. |
||
assert.True(t, got.Success) | ||
assert.Equal(t, "", got.Diff) | ||
} | ||
|
||
func TestFileMatcher_ValidateFails(t *testing.T) { | ||
m := FileMatcher{} | ||
got := m.Match("zoom", "zoologist.txt") | ||
assert.False(t, got.Success) | ||
println(got.Diff) | ||
assert.Contains(t, got.Diff, "+zoologist") | ||
assert.Contains(t, got.Diff, "-zoom") | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
zoologist |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
zoom |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you mind adding a failing case as well?