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.
The number of random tests is way too high. Debugging becomes a chore and my browser crashed a few times.
Function signature is incorrect.
Should be
fn number_check(v: Vec<&str>, m: u32, f: bool) -> Vec<String>
instead offn number_check(v: Vec<String>, m: u32, f: bool) -> Vec<String>
Just a hunch, but beta is a ruthless process. If your kata isn't (nearly) perfect or interesting, or novel, from the start, chances are it will be downvoted. After so many downvotes, it's automatically retired. Without random tests, most power users will downvote immediately.
There are a few options.
You definitely need to add random tests, ideally 100-200, to prevent hardcoded solutions.
As far as I know katas can't be deleted if they have completions. Keeping it in a draft state is the only option. Nobody else can submit a solution if it's in draft.
This has been done before unfortunately: https://www.codewars.com/kata/578bf2d8daa01a4ee8000046
Let's go with yes, and if another bypass happens, another issue can be raised.
So, full disclosure, I haven't authored a kata in ages, and I'm certainly no expert in how to restrict certain things. Looks like there's another solution that currently bypasses your restrictions though.
This comment is hidden because it contains spoiler information about the solution
.
You're welcome. Looks like this issue is resolved. You can go ahead and republish this kata when you're ready.
in addition to the other issue raised, descriptions should be written in English.
Fixed and random tests should be separated out into their own
describe
/it
blocks. I'm creating this issue to force this kata back to draft as I believe the floating point comparison issue I raised is going to piss a lot of people off.81.83333333333334 should equal 81.83333333333333
You shouldn't be checking the equality of floats using
assert_equals
. You're essentially forcing users to guess the exact method you've used to calculate the result.You should use
assert_approx_equals
(https://docs.codewars.com/languages/python/codewars-test/#approximate-equality-tests)Loading more items...