5 kyu
Argument Mapper
597ohager
Loading description...
Reflection
Fundamentals
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
No random tests
Node 12 should be enabled
Tests are using
Test.expect.Fool's kata. Waste of time. You cannot depend on parameter names in JavaScript. Give up now.
You cannot, that's true. But this is a dojo here... and the kata should give you an insight. btw: In Karate you won't defend yourself running a kata (e.g. Empi or Unsu) when you gonna beaten up by some rude guys.
Broken analogy. Dojos do not intentionally teach bad habits.
Why not change it to an actual useful task like mapping an array of values to an array of keys or something?
Sure, it's a lot easier of a problem, but at least it makes sense and trains you how to do something that is useful.
And there's still "insight" to gain...
Nice one, but I believe the description could use some improvements - specifically, I think it should be more specific about the argument names.
There's no information indicating whether the argument names should be extracted from the value (as the usage example might imply) or fixed arg names should be used (as the test cases seem to indicate).
I'm guessing the latter was the original intent, but seeing how most solutions focus on parsing the values, the description definitely is not clear enough in this regard.
Lack of test cases. Results of the solutions will be unexpected with below code.
Have I to preserve original parameters names?
Yes.
Nicely done. The "Assert" message is a little ambiguous. If you made it somehting along the lines of
Assert: argumentMap['a1'] == 'a1value', that would be much more obvious what's going on. Out of interest, is there a reason you aren't usingTest.assertEquals(result, expected, message)?Thanks for feedback. I considered your suggestion and applied it. There's no special reason why I chose 'expect'. IMHO the code sounds slightly more natural with test.expects() than with test.assertEquals().
The failure message for one of your test cases is "Assert: a1 = 1]". It should say "Assert: a1 === 1".
Fixed. It says "Assert: a1=1" instead of "Assert: a1===1".
Thanks. The stray bracket was the main thing I was trying to point out.
Cool, nice one!