This process has been really crappy, and not supportive at all, in which I recieved insults from a user. I doubt my comments will make much of a difference, and I understand that, which is why I doubt I would waste time submitting anything else, unless I had an abstract idea for a "story style" problem. Pretty much anything algorithmic in nature is probably a "duplicate". This is asimilar to the fact you'd never return to a makerspace in which people just called you lazy for forgetting about a small part of a project, and then threw your project in the garbage. It was a good go at learning about generating random tests, though.

.

When redoing this

I don't see any point in this. There're plenty of katas asking you to implement a binary search either explicitly or implicitly, and creating any more of these will not benefit anybody. If the author thinks he's going to make something worthwhile by coming up with a generic idea after having completed 30(!) katas, I have bad news for him...

Unfortunately, retirement is final.

You get a second chance at publishing your first kata though.

OK, it's now retired so it can't be saved anymore. When redoing this ( which I think is worthwhile ), fix all reported problems before publishing and you have a shot at a survivable first kata.

Closing this now.

Good luck!

I have commented somewhere above here with a buggy algorithm that ( mostly ) isn't caught by your testing. That is what I was referring to.

The problem people refer to when shouting "Duplicate" is the one referenced in Wiki - Kata Best Practices - Make Sure Content is New. If the concept behind a kata isn't novel, it needs some additional oomph to not be a duplicate. Actually, the additional logic you require does spur a bit of identity, but publishing a first kata without sample tests, with input that can be modified and with problems in the reference solution ( even if - kudos - it has random tests. but all of its problems aren't new to us ) makes us think you have not read available documentation, not learned enough from solving existing kata ( and reading their tests and comments ) and generally not spent enough effort that we should be required to spend effort explaining in detail what we think you did wrong. This can be counterproductive, and often is, but publishing kata that feel unfinished is also counterproductive - experienced people on here will not tend to think "let's explain the new author the ropes .. again".

I don't know if this kata can still be saved. You really have to get most everything right before you hit Publish, or you will accumulate downvotes fast, and people may not come back to change their vote even if you fix the problem. Truly original ideas are hard to come by these days, with 6 000 preexisting JS kata. But, especially if you publish a new one that looks vaguely like an existing one, get as many things as you can right, right from the get go.

O(n) solutions passing tests should never have happened either. I think that one can be fixed by tweaking the performance parameters on a couple of large tests. 100 ms probably is just too much time still.

Thank you for presenting an actionable issue, and not calling me lazy. I've tweaked the description. :)

It's too subtle.
(And if every detail should be understood literally, a function that "should return an array with 2 elements that are integers" should never be expected to return null as an item.)

It is. bigArray => [ Number, Number, ... ] Reading through the description carefully would've netted you seeing that and spared me an insult.

So, I was unaware of the alternative definition of "Duplicate" that you suggest. Typically duplicate is an synonym of "identical". This kata requires some additional logic inside a bst algo, which should spur some identity. All of this is somewhat bike shedding - if it's a duplicate, let's kill it, if it's not, let me improve it and use your energy on this conversation to help me do so.

Saying it's not tested adequately is also not helpful or constructive, please tell me why and what I can do to improve that. I did attempt to override the Array indexOf prototype in the suite, but chai or mocha uses it under the hood and it breaks the test. Any ideas?

It was published!

Yeah, that happens. Just keep trying.

But please control yourself and don't close the issue until the fix has been published ( and even then, try to wait for confirmation. We're practically working with you in realtime here ).

@JohanWiltink The definition of "duplicate" is indeed identical - I didn't know codewars' interpretation of the word. I'm curious as to why you believe it's not tested adequately either and how you would improve on that? I'd like to learn some ways to validate solutions even further than what I've created, rather than just shoot the kata down because it's just a general BST test. When I first wrote the test suite, I did try and override the indexOf prototype, but chai uses it under the hood so it broke the tests. Any ideas?

https://user-images.githubusercontent.com/6146261/62568587-c98c0c00-b84a-11e9-9549-8c8d0a9061a6.png This is my current state of publishing. Validating works, but I cannot publish.

It would probably make more sense to improve testing, requiring an O(log n) solution, failing anything O(n) or worse.

With per test performance measuring, that should be doable.