Skip to content

tournament: Canonical data incompatible with new schema #714

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

Closed
rbasso opened this issue Mar 12, 2017 · 3 comments
Closed

tournament: Canonical data incompatible with new schema #714

rbasso opened this issue Mar 12, 2017 · 3 comments

Comments

@rbasso
Copy link
Contributor

rbasso commented Mar 12, 2017

While the valid_inputs object can be easily translated to the new schema, the invalid_inputs only lists invalid lines that should be ignored if inserted in otherwise-valid game.

To be able to proceed with #625, we first need to make all the test cases involving invalid_inputs explicit, or remove them completely.

@petertseng
Copy link
Member

petertseng commented Mar 12, 2017

Well, great, yet again it is my fault. You can see that I tried to get too clever in #287.

The tracks at the time were all mashing their invalid input lines into one case.

Allegoric Alaskans;Blithering Badgers;win
Devastating Donkeys;Courageous Californians;draw
Devastating Donkeys;Allegoric Alaskans;win

Courageous Californians;Blithering Badgers;loss
Bla;Bla;Bla
Blithering Badgers;Devastating Donkeys;loss
# Yackity yackity yack
Allegoric Alaskans;Courageous Californians;win

Since the file was added, no exists tracks changed their tests, but two new tracks added:

  • Ruby completed ignores the invalid_inputs test cases and never tests them (this implies the invalid_inputs cases are too hard to understand)
  • Lua does it faithfully

If I were given time to respecify the exercise, I would require that the invalid lines be errors instead of ignored (will require overturning #299 which I would be happy to have overturned), and then place the invalid lines by themselves.

If I were given time to add test cases, I'd also add tests with fewer input lines, since the first valid_inputs test asks the student to have absolutely everything working already, at which point the.

If nobody cares enough to do either, the minimal change would probably to put the invalid lines with a single valid line and have the expected output just be the output from the single valid line.

@rbasso
Copy link
Contributor Author

rbasso commented Mar 12, 2017

Well, great, yet again it is my fault. You can see that I tried to get too clever in #287.

Of course it is not your fault, @petertseng! It makes no sense to judge a decision based on posterior data and/or criteria.

If we are having trouble porting exercises you wrote/changed, it just proves that you contributed a lot. 👍

@rbasso
Copy link
Contributor Author

rbasso commented Mar 12, 2017

If I were given time to respecify the exercise, I would require that the invalid lines be errors instead of ignored (will require overturning #299 which I would be happy to have overturned), and then place the invalid lines by themselves.

I think that it makes no sense to ignore the invalid lines in the input. 👍

If I were given time to add test cases, I'd also add tests with fewer input lines, since the first valid_inputs test asks the student to have absolutely everything working already, at which point the.

I also agree that more focused test cases, with fewer lines, would be a great idea. 👍

If nobody cares enough to do either, the minimal change would probably to put the invalid lines with a single valid line and have the expected output just be the output from the single valid line.

I did just that in #717 (I hope I did it right), so that we can immediately proceed with #625.

If someone decides to rewrite it later it would be great!

emcoding pushed a commit that referenced this issue Nov 19, 2018
RNA Transcription: Correct abbreviations in user-facing descriptions
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

No branches or pull requests

2 participants