What you're doing with those highly restrictive reader/writer is pointless. There are ways to do this which are much better and yet you chose this method which provide crappy interfaces and pointless restrictions.
e.g We don't even know if a reader is closed. What if one of the returned elements is undefined?
makeStream isn't defined when testing, only when submitting.
Also, are we supposed to close the output stream when done, or is that only for convenience? I didn't, but it passed anyway.
Last, I don't really see the usefulness of an isWiggled method if you can't write un-wiggled streams (it throws an error). So that function will always return true. Yes? Doesn't hurt anything, just kind of pointless.
The error messages for failing tests are way too long (they repeat 'You do not have the right number of elements' a couple of times). Also, there are a few typos in the Instructions section.
Thanks! You're totally right about the cases, not sure why I upper cased them...
And I'm still not entirely happy with the testing for this kata. I've added a method to the writer to allow easy checking of wiggled-ness, and put in a test case to use it.
Hope that helps!
A good idea for a kata. Just a couple of minor points:
Arguments/variables generally start with lower case letters, upper case is convetionally used for class names.
Either produce a test case that satisfies the kata system or none at all. ie, move the test case code into the description.
Nice one ... I think I'm going to have another go :)
It is not necessarily always possible to write a wiggle-sorted output stream.
Will we only be passed input streams that should make it possible?
Your tests is woefully inadequate. There are only sequential arrays so there is only one pattern in which we would get stuck.
Needs at least more tests and random tests.
What you're doing with those highly restrictive
reader
/writer
is pointless. There are ways to do this which are much better and yet you chose this method which provide crappy interfaces and pointless restrictions.e.g We don't even know if a reader is closed. What if one of the returned elements is
undefined
?makeStream
isn't defined when testing, only when submitting.Also, are we supposed to
close
the output stream when done, or is that only for convenience? I didn't, but it passed anyway.Last, I don't really see the usefulness of an
isWiggled
method if you can't write un-wiggled streams (it throws an error). So that function will always return true. Yes? Doesn't hurt anything, just kind of pointless.Hi,
The error messages for failing tests are way too long (they repeat 'You do not have the right number of elements' a couple of times). Also, there are a few typos in the Instructions section.
Cheers,
Thanks! You're totally right about the cases, not sure why I upper cased them...
And I'm still not entirely happy with the testing for this kata. I've added a method to the writer to allow easy checking of wiggled-ness, and put in a test case to use it.
Hope that helps!
A good idea for a kata. Just a couple of minor points:
Nice one ... I think I'm going to have another go :)