Standard test suite for pascals-triangle #362
Conversation
|
In commit message and PR description, link that should go to Kotlin goes to Ruby instead |
|
A curiousity I found when I did this exercise in Java was that Java's tests have a |
|
I didn't notice it in Java, but I did spot it in..Perl, I think. Yeah, I think it's outside the scope of the problem. |
IanWhitney
force-pushed
the
pascal_triangle_test_suite
branch
from
10f596c to
a6e1411
Compare
| }, | ||
| { | ||
| "description": "no rows", | ||
| "count": null, |
There was a problem hiding this comment.
in some languages it will not be possible to pass null in place of an integer, but I assume they will just skip that.
Speaking of "no rows", should the input of 0 be tested?
There was a problem hiding this comment.
I think that, to keep consistency, zero could be a valid input returning an empty list [], if we really want to test it. It seems the natural base case to me.
Number of lines must be natural, so I agree that negatives can be considered invalid input if the type system cannot enforce positive numbers. That said, I would not criticize a solution returning an empty list for negative inputs.
Should we test those cases ❓
IanWhitney
force-pushed
the
pascal_triangle_test_suite
branch
from
a6e1411 to
58ee2a8
Compare
Official tests have not been merged yet, but I'm mostly following them here. exercism/problem-specifications#362 I thought I could use `should_panic` to test a negative row count, but no. It won't compile since I'm violating type safety. I've left that test in, but plan to remove it before merge. Example code is naive. Just enough to pass the tests. A real example solution will come later.
As discussed here: exercism#362 (comment)
|
Seems great! 👍 |
In surveying the current implementations, I found 2 main approaches: - Test 1, 2, 3, 4, 5 and 20 without any boundary checking - [Ruby](https://github.com/exercism/xruby/blob/e50b1cbeabc3a82c1ed7800da112b0984dbbf01c/exercises/pascals-triangle/pascals_triangle_test.rb) is a good example - Test 4 & 6 rows, and test boundaries - [Kotlin](https://github.com/exercism/xkotlin/blob/02ecc5a70719f0b0e741992f33879f880f7c407f/exercises/pascals-triangle/src/test/kotlin/PascalsTriangleTest.kt) is a good example Also, some languages exposed specific functions for `rows` and `last_row` while some relied on built-in functions for this behavior. In this approach I'm trying to meld what I see as the best of these worlds. Rows function ____ I think these functions should be implemented by the students, so I'm highlighting them as functions to test We decided that `last_row` functions were not necessary, since they would mostly only alias existing language functions (`pop`, `last`, etc.) Fewer Tests ---- Once a student has gotten 4 rows to work the probably have the algorithm down. No real reason to test larger numbers that I can see. Test Boundaries ---- An upper-limit test seemed unnecessary and very language-dependent. But catching Nil and negative inputs seemed like useful things to test.
IanWhitney
force-pushed
the
pascal_triangle_test_suite
branch
from
ab8f8f6 to
094bfd7
Compare
Official tests have not been merged yet, but I'm mostly following them here. exercism/problem-specifications#362 Example code is naive. Just enough to pass the tests. A real example solution will come later.
Suggest adding BookKeeping near end of the file
In surveying the current implementations, I found 2 main approaches:
is a good example
Also, some languages exposed specific functions for
rowsandlast_rowwhile some relied on built-in functions for this behavior.In this approach I'm trying to meld what I see as the best of these worlds.
RowsandLast RowfunctionsI think these functions should be implemented by the students, so I'm highlighting them as functions to test.
Fewer Tests
Once a student has gotten 4 rows to work the probably have the algorithm down. No real reason to test larger numbers that I can see.
Test Boundaries
An upper-limit test seemed unnecessary and very language-dependent. But catching Null and negative inputs seemed like useful things to test.