Ad
  • Custom User Avatar

    I confirm that the typo still exists

  • Default User Avatar
    1. print the inputs, so that you can see them in the console
    2. with that point above, "6 should equal 5" tells you all you need to know: 6 is what your code returned, 5 is the expected value.
  • Custom User Avatar

    I'm sorry, maybe I wasn't able to explain my issue properly; I have a piece of code that passes a few tests that I run locally, but I'm unable to pass the "hidden" tests of the kata because I receive the message

    "6 should equal 5". 
    

    Ok then, what is the test that fails? How do I debug code that fails to pass a test I don't see?

    Test.assert_equals(get_total_primes(10, 100),  4)   # [23, 37, 53, 73]
    Test.assert_equals(get_total_primes(500, 600), 3)   # [523, 557, 577]
    

    These tests pass; every other test I can imagine and write passes as well.

  • Default User Avatar

    just add print('something') to your code. Also make sure the code doesn't time out by including something like if b > 1000: return 'stop'. This way you will see the printed output.

  • Custom User Avatar

    Well, if I can, please tell me how :) I looked for a button that uncovered the hidden tests for quite a long time.

  • Default User Avatar

    @pochmann: look at my solution, you'll see the thing at the first line of code. ;)

  • Default User Avatar

    or you need to know the right tools to solve that as a 6kyu. ;) (this kind of problem is pretty generic on CW. Maybe we are too much used to them...)

    hint: try to find a way to not generate the useless numbers in the input range (note that this kata wouldn't be so much easier in a language other than python. That should give some hints too. ;)

  • Default User Avatar

    The point is that you learn how to debug your own code, receiving inputs you don't know about. Here, on CW, you're not on codefight: you can print/see the inputs of the "hidden" tests... ;)

  • Custom User Avatar

    What is the point of having tests that do not cover all the cases covered by random tests? My code fails because of a test I can't see. So I must guess what's wrong without actually knowing what's wrong. It's pointless (also, against TDD).