On Tuesday 02 April 2002 13:21, Jeffrey P Shell wrote: > On 4/2/02 2:51 PM, "Tavis Rudd" <[EMAIL PROTECTED]> wrote: > > How about starting with the distutils stuff? It's one part that > > should be fairly easy to isolate and apply to the official > > codebase as a patch. I'll do some work on this later this week. > > I'd appreciate any comments on the code (thanks Jeff) and the > > ideas behind it. > > > > The test code is a higher priority, but it's alot harder to > > isolate. > > I have some comments on this too, at least in regards to unit > testing. > > I see the 'assert' statement used a lot in Webware and related > code. It's a good thing to use, but how much code depends on those > assertions running all the time? I ask this for a couple of > reasons - (1) You can sometimes get a decent (but not huge) speed > increase running Python in optimized mode, but since the 'assert' > statement is basically a debugging statement, they get deleted from > the optimized .pyo files. This isn't a bad thing - if all of the > assertions have succeeded for a good amount of time, why waste > cycles depending on them in a deployment situation?
I agree. At one stage I considered writing a tool that removed 'if debug:' statements like the Python optimizer, but gave you a little more control about which debug statements should be removed. That way you could add lots of debug code to Webware for testing and then change a setting during installation to totally remove that code for actual deployments. > (2) The default exception raised by PyUnit is AssertionError, and I > used to see (and write) many unit tests using the 'assert' > statement. I've seen a few debates, primarily stemming from the > PythonLabs group, about whether this is right, and I've been > convinced that it isn't - if an assertion fails inside of tested > code, you want to isolate that from normal test failures. > Fortunately, PyUnit (at least, the version in the Python core) > seems to let you change the failure exception used to track test > failings (where statements in the tests themselves fail, versus in > the tested code), so this shouldn't be too big of a deal. I'd > recommend making a Webware specific test runner (or subclass of > unittest.TestCase) to use for unit tests that use a Webware > specific failure exception, and recommend that test authors use the > 'assert___()' or 'failUnless___()' methods of PyUnit instead of > blanket 'assert' statements. That way, even optimized code could > be tested. This isn't as much of an issue with testing WebKit as the functional test cases will be running in a separate process from WebKit. However, this is an issue for unit tests of individual modules and functions that will be running in the same process. Tavis _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
