Gregor Lingl wrote: > One question in this respect - how important do you consider > backward compatibility. When designing a new module the requirement > backward copmpatibility can have a big impact on the code although it > may in some parts be questionable. As an example let me mention the > radians() function.
It's fairly important. Text books have been written that refer to the turtle module; the examples in these text books must continue to work. As we don't know what features these examples use, we must rather err on the conservative side, breaking the API only for a very good reason. > Yes,, and I have some ideas in this respect, but mainly a prioncipal > question. I read about using doctest and unittest, but how does one > devise automatic test suites for graphical output. It might be ok not to verify the output. OTOH, this is a canvas widget, so it should be possible to get all items on the screen at any point with primitive canvas methods. These could then be compared to precompiled lists. > In the end it > depends on how it looks like. That was one reason, why I made my > example scripts. I use them for (not automatic) testing and I can > _see_ if things go wrong. Example: how do you test automatically if a > shape is filled correctly or not (as in the above mentioned bug)? You could check whether there is a polygon with the "right" shape, where "right" is specified by a series of coordinates. This is regression testing, and perhaps also coverage: we want to know whether changes to the module effect the current behaviour. When we test discovers a behaviour change, somebody manually will have to determine whether the test is wrong or the new code, and update the test if it is the former. Thanks your investigations about the current turtle.py. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
