Sophie gilder RPS

[sophiechannon]

No description provided.

[leoht]

Great work, well done! Sorry for the delay in reviewing this - not much to add aside a few small suggestions here and there. Feel free to ask me if you have more questions on that feedback :)

[leoht]

Usually it's best to enforce the view name to be something specific, rather than the return of a method that you might not fully control — for example, tomorrow you (or someone else) might modify select_type to return a different value, but might also forget to add a new view to cover this case here, which would break the program. Rather than coupling tightly the return value to the view name, it might be better to add some condition and specifically select the correct view — or better, to have a generic single view that is always used, but using an instance variable and some dynamic ERB tags to display a slightly different portion of the HTML, depending on the value

[leoht]

Same remark than above here — you could set the result in an instance variable and display something different in the view depending on this

[leoht]

It's good you've designed the routes beforehand here — it probably helped a lot your decisions in terms of routing, and how the application would behave, HTTP-wise

[leoht]

Minor one - usually symbol names are always lowercase

[leoht]

Nice use of helper methods here — to improve it, something good could be to add arguments (e.g to pass the player name) so, when calling the helper in your tests, the names the tests should expect become more explicit:

# Example

enter_and_submit_name_single('Rosie')
click_button "Scissors"
expect(page).to have_text "Rosie selected Scissors"
# ...

[leoht]

It might be good to have a test as well that checks it returns false when it is not a single player