• Please, add random tests which check not some 10000000...-th element but a whole list generated by next()-ing though the whole matrix.

  • Sure, I'm not saying the situation is ideal. ;)

  • Which is why I said the test code is not defensive.

    Also, what these global variables are named is an implementation detail, and the tests should not depend on us doing the same. It'd have been an issue if it was other things.

  • why there is a test on this

    Currently, there is no test specifically on that (I asked for it. The author didn't do it) but the values are overriden at the beginning of the test cases. So what you'r asking for is actually that a specific test was made, with an Test.expect(condition, message, allow_raise=True) so that the executions are stopped? honestly, as long as the code cannot pass with wrong values, the test suite being stopped or not, I don't see a difference. The only useful thing would be a meaningful error message about that.

    If I don't define the 4 directions, the test gives an error (bad)

    What do you expect exactly when you remove parts of the ocde...? ;p Yes, that would be better (actually, "cleaner") to stop the executions and so on. But again, the code won't pass through the tests...

  • Define a custom object that overrides the [] operator (assuming you already specified that's the way to do random access, which you should also put into the description):


  • But the thing is:

    • If I don't define the 4 directions, the test gives an error (bad)
    • If I define them but in wrong values, the tests gives a failed test and then proceed without problems, which begs the question of why there is a test on this if the whole test code doesn't depend on it?
  • I thought it's obvious that you can't iterate backwards if you dont have random access property or don't know length (or cant slice), and i think it's a spoiler (kind of), but i put in description, thank you.

    which is not an iterator but an range object

    I didnt say that Table.data is iterator. Iterator is what Table.walk() should return.

  • the wrapper problem doesn't apply anymore since the last changes of the runner, even without a wrapper function.

  • Laziness requirement is not tested on the y-dimension.

  • Python
    Iterator must be lazy.

    And yet your lazy test is


    , which is not an iterator but an range object. Iterator can be infinite and hence does not guarantee to have a last element (in fact iterators don't even have a length property), so iterating backwards is not a valid operation if you're requiring laziness and iterators.

    It means that your requirement is bogus and it should either be corrected or removed.

  • Python: There's no reason to check if the four direction global variables has to be specific values. And if not defining them breaks the tests, the tests not are defensive enough and it's bad. (It also means the tests is not wrapped in a closure, which brings other problems.)

    Please wrap the whole test code into a function, define the variables inside the function, then run it. Then it won't depend on the user defining the variables correctly.

  • remove the seeding, with that, the random test aren't random anymore. ;)

  • Oh, i see. Added test for this. Thank you.

  • Loading more items...