Are the tests not the same for all?

The test you claim you're getting does not and can not exist. A js number does not hold any information about leading zeros, it is of your own invention.

This one test did not get passed, so I decided to not go further and see the solution. Surprisingly, other solutions were the same as was mine, so not taking care of the leading 0 case. How come? Are the tests not the same for all?

Please read this: https://github.com/codewars/codewars.com/wiki/Troubleshooting-your-solution I really have no idea what you're talking about. There are almost 39k solutions in javascript already.

Just checked. Nothing's wrong with the test case. Leading zeroes must still be kept

I think test doesnot work with number leading with zero or ending with zero. It expect me to get defferent answer . I also checked in test changing the number to 2200 ..it expect me to get 18 .

0112 is the same as 112

Yes. Which is why, you will never receive 0112 as input. That's why it didn't happen.
That is convincing, right? We can rule that out.
myfunction(0112) <-- myfunction is going to receive 112, it will not be able to see "0112" in any shape or form

And if that is ruled out, then, you found 0112 somewhere else.

Additionally, looking at the test code, there is no such case. But the above is sufficient to already know that's not what happened.

So it comes down to re-measuring, because the measurement of 0112 can't be. And yeah you might not successfully do this but ... that's okay.
Typically what you can do to measure input is to print it out as the first thing you do in your function. For example:

func descendingOrder(of number: Int) -> Int {
  print(number)
  return number
}

Ideally you'd also figure out how you mistakenly found 0112, just because it's good to understand what went wrong.

If on the other hand the tests were based on strings and "0112" was generated, then you would still be receiving 112 and 2110 would have been expected. The test case would be 112 -> 2110. Yes that would be wrong, but that is also not happening and it wouldn't be 0112 -> 2110 which cannot be. It is however plausible that your code does this, that your code creates that string, converts it to int, loses the zero. That'd be something you created and that would mean you're measuring not the input but some intermediary state in your own solution.

natan,
I don't know how this test case worked but... "Attempt" did trigger this issue (0112 -> 2110). So if you ask me to remeasure (I couldn't, because "Attempt" blocked me from submission due to failure).

But as i mentioned... treating an Int in swift or Java, 0112 is the same as 112 (This happens before conversion of string). I would propose if we do find it, we should remove it.

There is no test with that input in javascript and the expected order is descending, so, no idea what you're talking about.

There are no octal numbers in play here, and the problem you have is not the problem you think you have. Leading zeros and octal numbers are not the same thing, and in this kata you should return an answer without leading zeros, but it has nothing to do with octal representation of a value. Simply not.

You'd have to read a bit on differences between representation of a number and its actual value.

Example with zeros would be good to have in the description though, that's for sure.

Hey! There was nothing said in specs about octal numbers as input (Expected: 2110, instead got: 1201). Please remove the test or at least add it as a spec so that people know what type of input to expect.

This test DOES exist. JS treats numbers with leading 0 as octal. After researching a bit I have learnt that it would be a bad practice anyway to use numbers with leading 0 in real life code, therefore I would suggest not to waste time to search for a workaround, but rather to remove this example from tests.