-
Notifications
You must be signed in to change notification settings - Fork 164
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
Puppy store error handling #557
Puppy store error handling #557
Conversation
Codecov Report
@@ Coverage Diff @@
## master #557 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 102 106 +4
Lines 1748 1826 +78
=====================================
+ Hits 1748 1826 +78
Continue to review full report at Codecov.
|
7a6f16f
to
4c5f9a9
Compare
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.
I made some comments on map_store.go
that also apply to sync_store.go
. I also made some comments on storer_test.go
once, but they apply multiple times across the test functions.
But overall this is good Go code - it reads well and is idiomatic.
07_errors/runnerdave/storer_test.go
Outdated
r.NoError(err, "Should be able to read updated puppy") | ||
assert.Equal(targetPuppy, updatedPuppy, "Updated puppy should be equal to puppy2") | ||
|
||
// cleanup |
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.
Rather than requiring cleanup in each test, you should use SetupTest()
and/or TeardownTest()
to ensure a clean state. I suggest in your suite, you have a constant or function describing which sort of store to create and add a SetupTest()
method to create the store fresh for each test. Then you can get rid of cleanup altogether and you know you can't get test failures because you didn't clean up properly at the end of a test.
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.
Hi @camh-anz, thanks a lot for your feedback I learned a lot implementing it, it should be ready now.
d6e4e0f
to
7e28d16
Compare
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.
LGTM. This is looking really good now.
I've made a couple of minor comments which you can address or not. Up to you. If you do, ping me on slack and I'll re-review quickly at my earliest availability.
|
||
func TestStorer(t *testing.T) { | ||
syncSuite := storerSuite{ | ||
store: NewSyncStore(), |
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.
Since SetupTest()
sets store
at the start of every test, this does not need to be initialised here - you can just leave it as the zero value (nil).
storerType: func() Storer { return NewSyncStore() }, | ||
} | ||
mapSuite := storerSuite{ | ||
store: NewMapStore(), |
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.
Ditto
|
||
// DeletePuppy deletes a puppy by id from the store | ||
func (m *MapStore) DeletePuppy(id uint16) error { | ||
if _, ok := m.puppies[id]; ok { |
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.
Usual Go style would be to test for !ok
and return an error, leaving the non-error case at the left edge of the function: https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88
In ReadPuppy
you couldn't really do that because of the scope of the puppy
variable was the if
block, but in this case you are ignoring that variable.
But this function is small enough that it doesn't really matter, so don't worry about changing it unless you really want to. Just keep it in mind in future - if it could go either way, keep the happy path at the left edge.
Fixes #103
Review of colleague's PR #513
Changes proposed in this PR: