Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
Same here
signature [1.8190803733637595, 10.32113085317588, 2.4538921407466985]
It should work with random inputs too: arrays first differed at element [25]; expected:<9145259.517695228> but was:<9145259.51769523>
signature [4.523989247754125, 4.4306407266327845, 2.9433070582317944]
It should work with random inputs too: arrays first differed at element [21]; expected:<602130.3478075289> but was:<602130.3478075288>
signature [1.218691787383328, 7.628302847784772, 14.623238617452863]
It should work with random inputs too: arrays first differed at element [20]; expected:<778388.1052085671> but was:<778388.105208567>
Please, add random tests which check not some
10000000...
-th element but a whole list generated bynext()
-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.
done
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.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):https://stackoverflow.com/questions/1957780/how-to-override-the-operator
But the thing is:
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.
I didnt say that
Table.data
is iterator. Iterator is whatTable.walk()
should return.How should i test it?
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.
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. ;)
Loading more items...