5 kyu
There are two kinds of people
109 of 142joh_pot
Loading description...
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.
The description formatting is broken.
fixed
Ruby 3.0 should be enabled, see this to learn how to do it
This comment has been hidden.
Functions that return lambdas should be allowed in Ruby as per the description and basic cases, but the full tests expect a hash.
This comment has been hidden.
Even with the current calling convention, it should work, since a lambda called
function, for example, can be called like so:function[argument].Blame him for writing that very lazy test in random tests then. He literally just did this:
which is completely different from the JS version, and is also implementation specific (it forces a specific type of solution).
See, this is why I hate shoehorned translations and insufficient specs in the original kata descriptions. Things like this really happen all the time, and people never learn.
If
anything can be returnedthenTest.expectin fixed tests is a bad choice because it doesn't test the keys actually exist, it only tests if the final value is truthy. So if I returned0/false/''(or evenundefined, because I can!) in the last step they'll fail the fixed tests.And if you allow literally anything, here's a much bigger problem: tests of the form
.there().are().two().kinds().of().people().apparently()(with additional, invalid calls after the intended line). In this case what exactly is expected? If you don't constrict what the return value from the last call is, this is undefined behaviour.I hear what you are saying about Test.expect. It enforces that you have to return a truthy. When I wrote this I really didn't care what you returned, I just wanted to see if the final function exists. This does cause an issue if your final function exists but returns anything that is not truthy. If you go down
Test.assertEquals, how will you make it so that you just want to see if final function exists and you don't care about the return value? As for you second statement, if you want to add more functions than what is necessary, go ahead, I only care about whether the string that I'm sending in gets converted to methods.Right, but if your requirement is loose, it's very hard to write tests that encompasses all situations that are valid by your rules, and that would be your test's fault for not accepting them, i.e it's everything but defensive.
I have even more examples that will cause your tests to go wrong:
undefinedexcept for the active oneProxythat says all keys exist but won't return anything unless the key is rightSo what I'm advocating there is to have a requirement that is comprehensive and won't get out of hand like the above, so people with weird ideas won't get weird/wrong behaviours from your tests, and you too can test the behaviour more easily. A key part of kata design is to be the adversary yourself, which I do often: if I can easily come up with many ways to break my tests, they're not good enough and needs to be re-written.
The kata is not a 1kyu. It is quite simple, make sure you have all the strings as functions. The checks are simple and good enough for this kata. As you can see, heaps of people have completed it almost the same way, which I was expecting. I'm going to change the description to say that your final function needs to return any truthy value. I'm honestly not going to bother to cover every possible scenario where you can return some value that passes or don't pass. If you want to spend some time rewriting this entire kata, please go ahead and do so. If I could delete this kata, I would because before you decided to nitpick every single thing on this kata, it was humming along just fine.
I'm not "nitpicking every single thing on this kata", FYI: If you go to see those katas which has several thousands or more solves, lots of people are doing stuff in completely different ways and they'll hit upon lots of things; I'm just simulating this process. And 82 solves are far from "heaps of people", it's not even close to the 500 solves limits katas used to have; it's far from enough to get someone point at things that can go wrong.
If other users attempting your kata is pointing out the same thing I'm doing here, it's still your fault, not mine. The kata is yours. If someone's code perform exactly according to your spec and the tests rejected it, it is an issue. Deal with it.
That being said, I haven't done anything on the JS version yet because the expected behaviour of
.there().are().two().kinds().of().people().apparently()is unknown. I'm still respecting you as an author that's active that I haven't just rewrite the whole thing myself, so please consider that too.No mate, you spend hours going through katas trying to find issues. Now I don't really mind it, I appreciate it but there is something about your tone and level of smugness that just grinds my gears. It is simple, here is the kata, these are my tests, if you pass, awesome, if you don't, make it pass. Do you get it? Now, if you have an issue with that, fix it. Or, add a feature request so that authors can delete their katas.
Closing.
Test.expectis used in JS version, which means it's crap: any truthy value passes all the tests. Nothing is enforced at all.How would you pass the kata just by using any truthy value?
Try changing your test from
Test.expecttoTest.assertEquals(..., true). Even your own solution fails against that, because it's not actually returningtrueat the last step, but a function.I'm fixing both language version at the moment so I guess you can wait while I fix all the things listed below.
I don't care about whether it returns a truthy or not, the test is to check if you have all the keys in there. If you have, you can return anything.
Test.expectis the right choice, I made it on purpose. Please leave it alone. If you want to fix tests, add the edge case tests or whatever other thing you find.It's not resolved.
Ugh, I'll reopen a new issue.
It is resolved. The expected behaviour is to have the functions in there, it DOES NOT MATTER what you return in the end.
Test.expectis used in JS version, which means it's crap: any truthy value passes all the tests. Nothing is enforced at all.duplicate
Edge case
''(empty string) missing.Not concerned about edge cases.
There are also no tests on whether the correct keys are enforced, or whether things will not break if you use many instances at the same time.
I'll just rewrite the tests myself.
Closing
JS and Ruby have completely different requirements: JS expects
functionator('there are two kinds of people').there().are().two().kinds().of().people() === truewhile Ruby expectsfunctionator("there are two kinds of people")["there"]["are"]["two"]["kinds"]["of"]["people"] == true, and only the behaviour of JS version is mentioned in the descriptions.This comment has been hidden.
Ruby expects
functionator("there are two kinds of people")["there"]["are"]["two"]["kinds"]["of"]["people"] == true.This comment has been hidden.
Opening an issue for this.
not sure what does this mentions: "Please note that these chainable calls do not return the current object"
always failed as following: symucxkj() should not exist in same object as xdtrlqbx(). Chainable calls should not return current object! - Expected: true, instead got: false
There should only be one function per word in the current object. This means when you do
thereonly that should be on the current object, no other methods from the rest of the words are allowed in there.Approved
Awesome. Thanks mate.
In the description, a mention of the expected final function value (i.e.
true) would be nice.The final function doesnt have to return true. I dont test for it.
I closed this too soon.
You don't test for it in the random tests. But in the example and fixed tests you do, because of
Test.expect(so any truthy value will do).Another thing: Did you disabled the
Function.prototype.toStringmethod? Because for some reason trying to usetoStringon every function in this kata gives an empty string, even for native functions.He did.
Joh_pot, it's fair to do this, but it should be mentioned in the description.
I do this to disable users looking at the random tests as well as leaking my solution by doing a console.log(arguments.callee.caller.toString())
I don't think that's a good idea given that this kata requires a lot of debugging functions.
Is it possible to use Node's
vmand run the code inside? Then I think it should be separated from the test environment itself.Random tests are always broken.
It appears that it's not even calling the first function correctly.
Im not following. How are the random tests always broken? It is calling the functions.
This comment has been hidden.
I can assure you that the random tests are calling the functions. If it wasnt, my solution or @kazk's would not have passed. This a snippet of the random test:
if (valid[0]) { Test.expect(true,true); obj = obj[arr[x]](); } else { Test.assertEquals(false, true, valid[1]); return; }Voile, are you returning an object, or, perhaps, the top level function?
Closing issue.