-
-
Notifications
You must be signed in to change notification settings - Fork 666
all-your-base: add test generator #945
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
all-your-base: add test generator #945
Conversation
ferhatelmas
commented
Nov 10, 2017
- with putting assumption into hints
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.
Seems the canonical-data.json forced some test cases to now be errors which were not errors before, at least in the Go track. Oh well. There's not much way around that if we use that data.
I prefer preserving the error return value instead of a null slice. Test data can remain the same with adjustments to the example and the test program. But your choice.
} | ||
|
||
if !digitsEqual(c.outputDigits, output) { | ||
output := ConvertToBase(c.inputBase, c.inputDigits, c.outputBase) |
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.
Dropping the explicit error return value and collapsing all the errors to a nil slice seems a bit atypical.
@leenipper Hold on this, there is an ongoing discussion and improvement: be explicit about errors[problem-specifications#1001] and be decisive about zeros[problem-specifications#1001] |
Ok. Let it sit until some consensus. |
b0e96e5
to
3391d09
Compare
@leenipper @tleen updated for review. |
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.
Looks good. Only one optional item.
Handle problem cases with following messages: | ||
* input base must be >= 2 | ||
* output base must be >= 2 | ||
* all digits must satisfy 0 <= d < input base |
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.
Since the test program does expect exact error match,
I'm wondering whether more specific Go wording in hints.md would be helpful. Perhaps:
Handle problem cases by returning an error whose Error() method
returns one of these strings:
"input base must be >= 2"
"output base must be >= 2"
"all digits must satisfy 0 <= d < input base"
Reading the test program would lead to same conclusion. Your choice on this.
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 like the idea of hints as a more user-friendly way explaining expectations than using the test cases themselves. Although the test cases end up being the authority.
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.
@leenipper done so.
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.
LGTM
- canonical data assumption are hint file
3391d09
to
44ed5f6
Compare