Farzan's RPS game (2 user stories complete)#2109
Conversation
| @win = nil | ||
| @message = "" | ||
| end | ||
|
|
There was a problem hiding this comment.
this feels like neat logic - very easy to read
| end | ||
|
|
||
| private | ||
|
|
There was a problem hiding this comment.
You could consider keeping the computer in a separate class
|
|
||
| expect(page).to have_content("Farzan Vs. Computer") | ||
| end | ||
|
|
There was a problem hiding this comment.
Good, specific content requirements throughout the tests - I need to tighten mine up.
eoinmakers
left a comment
There was a problem hiding this comment.
Nice work on this! You've demonstrated the learning objectives of the week well.
My feedback revolves around refactoring to remove duplication of code - let me know if you have any questions.
You have a good range of unit & feature tests here, inc. stubbing the computer's move. Nice work! Fully comprehensive unit testing for this challenge would include unit tests for every combination of player/computer moves.
| @game = $game | ||
| @game.scissors | ||
| session[:message] = @game.message | ||
| redirect '/play' |
There was a problem hiding this comment.
Currently, you define a route for each player move option, and each of these routes uses mostly the same code. This is a duplication of code that could be refactored.
Another method of approach this logic is to pass in the player move as a parameter, calling the same route, and passing that param into the @GAMe instance.
| when nil | ||
| @message = "It's a tie! Try again!" | ||
| end | ||
| end |
There was a problem hiding this comment.
This approach can be simplified to make this class more concise. Check out the following approach: https://github.com/makersacademy/rps-challenge/blob/main/docs/review.md#use-of-ifelsif-conditionals-for-business-logic
Farzan Imanzadeh
Completed the below user stories:
Did not complete the bonus parts (multiplayer and RPSLS)