Skip to content
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

bowling: propose tests for err semantics #223

Closed
wants to merge 1 commit into from
Closed

bowling: propose tests for err semantics #223

wants to merge 1 commit into from

Conversation

petertseng
Copy link
Member

Specifically: if a call to roll() is made that results in an error,
the game state should not be altered, so that future calls to
roll() will proceed as if the erroneous roll never happened.

This is only a proposal because there was doubt in #213 about whether
they should be added.

Since it was suggested, after seeing it in my Exercism submission, that
I open an issue for it, I will, because I can let code speak to
accompany my words.

Right now there's no good way to express this kind of semantics in
x-common, but maybe a general discussion on it would be OK to brainstorm
some ways to do it.

TODO:

  • The current example solution needs to be fixed.
  • It is possible we can add more tests of this type - basically any time
    we expect an is_err() from a roll.

I would only want to put in the work to proceed with these if we decide
we do want these kinds of tests.

Specifically: if a call to `roll()` is made that results in an error,
**the game state should not be altered**, so that future calls to
`roll()` will proceed as if the erroneous roll **never happened**.

This is only a proposal because there was doubt in #213 about whether
they should be added.

Since it was suggested, after seeing it in my Exercism submission, that
I open an issue for it, I will, because I can let code speak to
accompany my words.

Right now there's no good way to express this kind of semantics in
x-common, but maybe a general discussion on it would be OK to brainstorm
some ways to do it.

TODO:

* The current example solution needs to be fixed.
* It is possible we can add more tests of this type - basically any time
  we expect an `is_err()` from a roll.

I would only want to put in the work to proceed with these if we decide
we *do* want these kinds of tests.
@IanWhitney
Copy link
Contributor

I still think this adds new behavior to the exercise that I don't think is necessary. It gets into the territory of "If I were to implement a real bowling scorer", and I think exercises shouldn't worry about what 'real world' solutions; instead they should be focused on a single thing.

@petertseng
Copy link
Member Author

petertseng commented Nov 8, 2016

It can sometimes be hard to know where to draw the line. We have seen before at #178 (comment)

But if people are using these exercises to learn how to write Rust and the exercises encourage smelly Rust code, then won't most of the students go off and write smelly Rust code in production?

I think currently we draw the line at essential behaviour, and we can't really say that this behaviour is essential to scoring a bowling game.

Another comfort we can take is that even though the exercise doesn't enforce the kind of discipline in error handling that we would be asking for in this test, at least it is not encouraging smelly code. We're leaving it open. So the stance we take is not inconsistent with the above quote.

I think if someone is very interested in error handling, they should help us implement the https://github.com/exercism/x-common/tree/master/exercises/error-handling exercise... where everything discussed here would suddenly become essential to the problem... since it's the entire problem.

@petertseng petertseng closed this Nov 8, 2016
@petertseng petertseng deleted the bowling-err branch November 8, 2016 17:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants