Hello (first post here ).
I have completed all tests in the winamax challenge, but when I submit my code the “Long game” test turns red, explaining to me that something is hard coded, that’s why it passed the test in-game and not during submission.
This is an obvious bug of the checking mechanism. My code has absolutely nothing hard-coded (except an array containing the cards from 2 to A, which again cannot be considered something that affects the string outcome of the game).
When the website tells you this message it does not mean that you are actually hard coding anything. It just states that the validation tests are different from the ones you’ve passed in the IDE. So your code is probably wrong somewhere but still does pass all the IDE tests.
You have two ways of approaching the problem : looking at the name of the failing test you can try to guess what the test does and where your code is failing, or come on the IRC and ask for help
Thanks for your reply.
The error message is pretty straight-forward: “The following validators differ from the puzzle test cases to prevent hard coded solutions. This is why you can have some fails here even if all of the tests provided in the IDE have been successfully passed.”
My solution is solid (7/8 tests passed post-submission, 8/8 in-game in only 45 lines of code including initialization). I might come on the IRC to make this 88% --> 100% just because my OCD senses are tingling, but I suppose it’s something that must be looked into.
I really think you misunderstand the message. It says the test case in the validation are different to prevent hard coding, it does not say that your code actually has anything hard coded in it . The tests are simply not the same as in the IDE
Well, I had a shameful bug. Greets to “Bob” for a fresh pair of eyes.
However, I hit the rare scenario when every test inside passes and a single one post-validation fails. I guess it would be nice to provide in/out.txts post-validation so that the coder can replicate the problem at hand somehow.
That would defeat the purpose of the validation tests.
Because you don’t know what gets tested in the validation tests you have to make sure to satisfy the complete problem description with every corner case.
If you knew the validation tests beforehand, you would just have to satisfy the part of the problem description that gets tested.
Actually,you could just use a map: keys -> INs values OUTs. Then you read input and you output the expected OUT.
As @chrm said, that just blow the whole purpose of validating.
If you think the scope of validators covers more area than the scope of given tests in IDE, do not hesitate to suggest it. We’ll look at it and add tests if needed.
I ran into the same problem on this game (and have not yet fixed it). All the tests pass but the long game validator fails. I suspect that the validators are covering an edge case that the main tests are not. It’s a bit annoying trying to debug the code without knowing what about the case is causing it to fail. At this point I am pretty much just guessing or staring at the code looking for possible bugs.
I guess various tests often cover extreme scenarios.
In the Batman game’s last scenario, you are presented with a 10000 x 10000 grid and have only 15 moves to solve it. The algorithm must be pretty much perfect for the code to work.
Yes, that would be taking it to the extreme. By the way, are you aware that this is possible in the two code size optimization games? Is that intentional?
This is intentional for optimization games. Else, people would struggle to understand validators to hard code some thing;(Imagine you must go north in IDE tests but validators do not need it.)
However some of us think this would be very interesting to have a better test coverage on optimization games so that you must really solve the game. That’s another approach that we do not use yet.
I also had the issue from time to time but except in rare cases, it was always with code that smell: copy pasted part, code that could be factored …
It’s not possible to have tests that cover every possible code path because if you do some dirty code, you can have plenty of special cases in the code that do not need to be special.
So one advice when you hit this kind of issue: look for places in your code where you have duplicated logic, imbrication of if/else, long switch/case etc … and ask yourself if you really need so many codepaths.
I also sometime unit test my puzzle solutions code. It’s not because you’re on codingame that it’s not worth ensuring your code is working as you expect while you’re writing it.
).
