I feel like I wasn't supposed to do what I did. It passes all my tests, not sure why it says failed tests but I guess because it's different than the original. That's disappointing.

The exersice here is about trying to identitfy code smells and then apply refactor techniques, if you run tests you will see some suggestions (as "statement method smells as long method (>20 lines), try extract method"). Agree it is not very clear, but you could use some refactor catalog as help (https://sourcemaking.com/refactoring/smells).

As 1st step you may try to reduce #of lines on statement method by using extract method (https://sourcemaking.com/refactoring/extract-method). Please let me know if you have any question.

regards,

It's not very clear how the refactor should be done.

Thanks for your feedbak, I really appreciate and takes in order to improve test cases, now they verify code doesn't have bad smells ;)

Thanks for your feedbak, I really appreciate and takes in order to improve test cases, now they verify code doesn't have bad smells ;)

Thanks for your feedbak, I really appreciate and takes in order to improve test cases, now they verify code doesn't have bad smells ;)

thanks for sharing this reference! I can't access to your example, do you have some documentation regarding how to retrieve code? I was looking for a while, but did't found how to do that

Just because this is a refactoring Kata doesn't mean that the Initial Solution provided to the user should already pass all tests - you should at least add a test or two that somehow invalidates the original (un-refactored) solution. This could be done in a few ways:

1. The Initial Solution provided to the user implements a valid but inefficient algorithm so it often times out well before all tests are executed. The user is then expected to come up with a much more efficient algorithm that should just pass all the tests in time (12 seconds).
2. The Initial Solution is valid but very long and cumbersome. An extra test is added at the end to confirm that the final solution does not exceed a certain maximum length (i.e. number of characters).
3. The Initial Solution is valid but does not use a certain feature that you want the user to discover himself/herself (such as a useful native Array method in JavaScript). An extra test is added at the end to confirm that the final solution uses this "feature" at least once, usually by conducting a regex test.

Here is one such "refactoring" Kata I have authored for your reference: https://www.codewars.com/kata/57861fd922542afb0b00028b

I was going to raise this as an Issue but I see that at least 2 other users have already done so so I will leave this as an ordinary comment.

There are ways to get the user code. Would it be possible to apply some algorithm to this, and have the tests check for changes, and compare the score according to the algorithm to the base score of the unrefactored code? At least you'll have some testing that way.

Otherwise, you could just publish a kumite and have people fork and refactor that. I think that's more in line with what you want. A kata seems like not the right tool for this job.

aha! I understood now what you are proposing!! Yes, there is no easy way to validate that code was changed and improved. Thanks for explain that, i just updated description.

Haven't seen this comment - generally the same as below...;-) So i'm out of this game...

The initial code completely works, so there's nothing to do here. It's your task to write tests to check if your special task is fulfilled or not (difficult only for "refactoring"). So if i only need to hit the submit button and the code is accecpted, this kata is solved and makes no sense. So at least you have to publish code with some errors and to check if this code works. It's more cleaning bugs and not refactoring, i know... Generally you can check the user code for used "elements/statements/..." too, but it's not so easy and not included that the "new code is better than the old code" (needs a detailed description too);-)...

The task is rewriting the code without changing the functionality.

So the tasks can't just test if the functionality is unchanged; they have to test if the code is changed - preferably for the better.

Yes, this is hard. No, this is not what tests normally test on here - normally, they test functionality. But you don't want that. So you have to write the tests to match the task.

Sorry, I don't understand your comment. But maybe I didn't exaplin well, this one is a refactoring exersice, you don't have to write test, just improve code by using refactoring catalog ;) so test are just passing.

Thanks for writting! I am new using this tool, not sure what is best for this kind of exercise (kata / kumite) or if I used it well.

Sorry, maybe I didn't exaplin well, this one is a refactoring exersice, you don't have to write test, just improve code by using refactoring catalog ;)