-
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
Implement CRUD puppy with interface #538
Conversation
2f62c1a
to
3ed57a3
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.
After a while staring at your code (and adding a few extra tests) I cannot work out what’s happening to your coverage.
However one thing which may help is if you conform to the go style of returning an error
from functions which have an error condition and testing against that.
Still don't think that should matter, but never know... (also worth mentioning just as a stylistic nitpick)
FWIW: I sometimes use the HTML view of coverage to help see what the tool's seeing, but in this case it told me very little.
Either way, this is the command I used:
go test -v -race -coverprofile /tmp/cover.out -covermode=atomic ./... && go tool cover -html /tmp/cover.out -o /tmp/profile.html && open /tmp/profile.html
FWIW 2: Tests I tried out were things like:
- doing non deep-equals checks of zero value returns
- calling the offending functions on a
nil
store (which obviously just crashes - alas precluding any coverage result. Whilst it's arguable that one might need to check for such things, surely that would cause coverage issues on your other functions too) - started adding a custom error to your code (for my own edification) but the task exploded - and was discarded - once I realised I'd have to update signatures and calls across most files and it's 2am :)
Hopefully it's not error related - as I removed all my error handling upon seeing Lab 07 outline! |
Please fix broken build and address @anzdaddy 's comments |
3ed57a3
to
81569b6
Compare
81569b6
to
a35ef1f
Compare
33a306c
to
1229a14
Compare
Codecov Report
@@ Coverage Diff @@
## master #538 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 182 185 +3
Lines 3446 3494 +48
=====================================
+ Hits 3446 3494 +48
Continue to review full report at Codecov.
|
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.
Great work, Just one think I would like to fix up.
From an interface level, we don't care about what ids are being created, only that they are different for any two Create
calls. IMO the Create test should just create two puppies and check the generated ID's are different.
Feel free to disagree and I'll approve.
06_puppy/patrickmarabeas/types.go
Outdated
} | ||
|
||
type SyncStore struct { | ||
uuid int |
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.
Interesting interpretation of uuid
you have there.
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.
Changed to uint
a := assert.New(suite.T()) | ||
id := suite.store.Create(Puppy{Breed: "Boxer", Color: "Brown", Value: "300"}) | ||
|
||
a.Equal(id, 1) |
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 think what @anzdaddy was getting at here is that TestCreate
should create 2 puppies, and check the second ones ID is incremented by 1 from the first, or at least different, think about what could be generating these id's if you don't know what the implementation is.
Otherwise, great tests.
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.
Done
1229a14
to
4b0de14
Compare
Adds the Puppy, Storer and MapStore type definitions. MapStore implements the Storer interface and supplies a NewMapStore factory function. - Uuid increment is handled internally by MapStore Create - Read will return an empty Puppy struct if provided uuid doesn't exist - Update returns a bool whether a matching identifier was modified - Destroy returns a bool whether a matching identifier was modified Lab 06 (anz-bank#537)
SyncStore implements the Storer interface and supplies a NewSyncStore factory function. - Uuid increment is handled internally by SyncStore Create - Read will return an empty Puppy struct if provided uuid doesn't exist - Update returns a bool whether a matching identifier was modified - Destroy returns a bool whether a matching identifier was modified Lab 06 (anz-bank#537)
Add empty main function and tests to pass build requirements
4b0de14
to
5d53a52
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.
Looking really good! Great suite of tests and really clean, well documented code. I have left a couple of comments throughout which I think would be nice to have. Also there is the empty main function, if you feel against what I have suggested then let me know, otherwise it would be nice to see something in there (even if it's simple)
package main | ||
|
||
func main() { | ||
|
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 find it a little strange seeing a blank main program. I know the description of the lab doesn't state what you need to include in the main, so you have technically ticked all the boxes, but I feel it makes sense to maybe create a puppy or something to give context to the work being done. Happy to hear your thoughts otherwise.
@@ -0,0 +1,56 @@ | |||
package main | |||
|
|||
type MapStore struct { |
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 be nice to see some documentation on the MapStore struct as well, since it is a part of the exported package.
"sync" | ||
) | ||
|
||
type SyncStore struct { |
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.
Again here with the documentation as well
Value string | ||
} | ||
|
||
type Storer interface { |
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.
Again here with the documentation.
|
||
func (suite *StoreSuite) TestReadNonExistent() { | ||
a := assert.New(suite.T()) | ||
success := suite.store.Read(100) |
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.
success seems like a strange name for this variable. Maybe notFound
or something which indicates that it didn't exist?
The go-course is now closed. Thank you very much for participating. |
Adds the Puppy, Storer, MapStore and SyncStore type definitions.
Fixes #537
Review of colleague's PR #536