Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
No fixed tests where the node's value is equal to its parent node's value. Random tests generate such cases way too rarely as well.
Fixed. Also, updated to
Node 14.x
.Just a minor clarification. if anyone is stuck, that's probably because you should not recurse into child nodes when the child is less than its parent.
I am not marking this as having spoiler content since this guideline is included in the description, albeit hidden inside the code block, titled "Example of a tree".
Test.assertEquals
and notTest.expect
Is it really an issue? ;-)
You can show the visual tree of your example, it's a 'nice to have'
I had more trouble interpreting the description that necessary. The: "counts how many nodes can be traversed from root without any child node having smaller value than its parent."
can be interpreted as
"find the longest non-decreasing chain from the root"
where the author actually means
"count the number of non-decreasing nodes reachable from the root".
The way to use
Test.randomize
is to create an array of test data, randomize it, then run the tests over the randomized list.Something like this:
Now, I wouldn't randomize every test, just a few at the end. Otherwise it becomes hard to solve, because you won't get the same results.
Another thing that would be a good habit is to use more meaningful messages — either within the
Test.assertEquals()
itself, or withinit
messages. For example, your setup could look like this:See how the descriptions explain what is being tested, rather than just the expected output? This helps immensely when a test fails. Now you are giving organized, categorized feedback on the results of the test.
Note: You can have multiple tests within an
it
block, but usually these are testing the same input data. Since you only have a single integer as output, there's not going to be multiple tests. (And example where you might have multiple tests is complex output such as Objects or Arrays, or testing how many times a function is being called.)Thanks for the detailed advice! I hope it looks better now, although I'm not sure if randomize is working as it should...
This is a nice idea for a kata. A few things that would improve it:
You need a little more detail in your spec. It's solveable as is, but more exact specifications could help with optmizing the solution.
null
be passed in?)Replace
Test.expect(test)
withTest.assertEquals(actual, expected, msg)
, like so:This is better on 2 counts:
Test.assertEquals()
will render both the expected value and the actual value, which helps in debugging, without immediately resorting toconsole.log
.Adding in a few more test cases might be good
If you do this, also wrap your test cases in
describe('category', fn)
andit('test description', fn)
blocks. The docs have examples on how to use these. These blocks make your test code cleaner and more structured.Add some randomization to your test cases.
Right now, it would be trivial to "cheat" by returning the correct answers. You can use
Test.randomize(array)
to randomly order an array, then test each item in that array separately. This is usually good enough to thwart "cheating". I usually prefer to have a separate set of simple, random cases just for this purpose.