Adding a test case to the array-flatten on the Kotlin track

Exercism Building Exercism
1

Sorry, I had no idea that you weren’t accepting PRs any longer. But in any case, I’ve openend one: flatten-array: test for heterogeneous lists by gypsydave5 · Pull Request #566 · exercism/kotlin · GitHub.

Just a missing edge case to ensure that solutions need to work for Collection<Any?>

2

Can you provide a solution that violates this test but passes the existing ones?

(I ask because I suspect the answer is no.)

1 Like
3

Third from top answer of the community solutions would fail it:

Is there an automated way to prevent someone from changing the signature of the method?

(I ask because I suspect the answer is no.) :stuck_out_tongue:

4

:)

Students can’t edit the tests. So if the tests rely on the signature, then we’re good.

1 Like
5

@gypsydave5 If this test is worth adding to the Kotlin track, presumably it is worth it to add it to other tracks as well. If you agree with this, you might want to propose to add this test to the canonical test data, i.e. exercism/problem-specifications, instead.

I expected the canonical data to cover more types, but it turns out only integers, null, and arrays are covered :neutral_face:
A test that uses, say, characters instead of integers might also (in large part) solve your problem, but might be more compatible with some other languages.

1 Like
6

Yeah - types are tricky in problem-specs. Not sure how that’s best handled. @ErikSchierboom how do we normally go about this?

@gypsydave5 I’ve reopened the PR and assigned it to @ErikSchierboom to have a look at for you :slight_smile:

Thanks both!

1 Like
7

The problem-specifications README says

  • Test cases must all be considered optional, insomuch that a track should determine per test case whether to implement it or not.

So both homogenous and heterogenous test cases could be added, and individual tracks could adopt these when appropriate.

1 Like
8

In this case I think it is not unreasonable to just add a new test case that uses strings.

1 Like
9

I’d suggest either changing the signature to List<T?> and pop a test in to handle another type in a homogenous list (which should work for other language tracks too…?)

Or leave the signature with a List<Any?> and add a hetrogenous list test (as in the PR).

10

@ErikSchierboom Are you against adding a heterogenous test case?

11

No I’m not, that’s perfectly fine.

12

Then I propose

  1. Adding both an homogenous and a heterogenous test to the problem specification, and
  2. thereafter including one or both of these new tests in the Kotlin track.
2 Likes