Re: [Bug #131480] __test__() should auto-exec at compile time
I just closed the bug report quoted below with the following response: I don't agree that unit tests should run automatically. Nor do I think adding magic to the language to support unit tests is necessary when it is trivial to add some external mechanism. I guess this topic could be opened up for discussion if someone else disagrees with me. Regardless, though, it's too late for 2.1. Jeremy
">" == noreply <noreply@sourceforge.net> writes:
Bug #131480, was updated on 2001-Feb-07 18:44 Here is a current snapshot of the bug.
Details: We can make unit testing as simple as writing the test code! Everyone agrees that unit tests are worth while. Python does a great job removing tedium from the job of the programmer. Unit test should run automatically. Here's a method everyone can agree to:
Have the compiler check each module for a funtion with the special name '__test__' that takes no arguments. If it finds it it calls it.
The problem of unit testing divides esiliy into two pieces: How to create the code and how to execute the code. There are many options in creating the code but I have never seen any nice solutions to run the code automatically "if __name__ == '__main__':" doesn't count since you have to do somthing special to call the code i.e. run it as a script. There are of course ways to run the test code automatically but the ways I have figured out run it on every import (way too often especially for long tests). I imagine there is a way to check to see if the module is loaded from a .pyc file and execute test code accouringly but this seems a bit kludgy. Here are the benifits of compile time auto-execution:
- Compatible with every testing framework. - Called always and only when it needs to be executed. - So simple even micro projects 'scripts' can take advantage
Disadvantages: - Another special name, '__test__' - If there are more please tell me!
I looked around the source-code and think I see the location where we can do this. It's would be a piece of cake and the advantages far outway the disadvantages. If I get some support I'd love to incorporate the fix.
Justin Shaw thomas.j.shaw@aero.org
[Jeremy Hylton]
I just closed the bug report quoted below with the following response:
I don't agree that unit tests should run automatically. Nor do I think adding magic to the language to support unit tests is necessary when it is trivial to add some external mechanism.
I guess this topic could be opened up for discussion if someone else disagrees with me. Regardless, though, it's too late for 2.1.
Justin had earlier brought this up on Python-Help. I'll attach a nice PDF doc he sent with more detail than the bug report. I had asked him to consider a PEP and have a public debate first; don't know why he filed a bug report instead; I recall I got more email about this, but it's so far down the stack now I'm not sure I'll ever find it again <sigh>. FWIW, I don't believe we should make this magical either, and there are practical problems that were overlooked; e.g., when Lib/ is on a read-only filesystem, Python *always* recompiles the libraries upon import. Not insurmountable, but again points out the need for open debate first. Justin, take it up on comp.lang.python.
Running tests automatically whenever the source code is compiled is a bad idea. Python advertises itself as an interpreted language where compilation is invisible to the user. Tests often have side effects or take up serious amounts of resources, which would make them far from invisible. (For example, the socket test forks off a process and binds a socket to a port. While this port is not likely to be used by another server, it's not impossible, and one common effect (for me :-) is to find that two test runs interfere with each other. The socket test also takes about 10 seconds to run.) There are lots of situations where compilation occurs during the normal course of events, even for standard modules, and certainly for 3rd party library modules (for which the .pyc files aren't always created at installation time). So, running __test__ at every compilation is a no-no for me. That said, there are sane alternatives: e.g. distutils could run the tests automatically whenever it is asked to either build or install. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Guido van Rossum -
Jeremy Hylton -
Tim Peters