Jon Ribbens wrote: > I guess, if you mean the part of the thread which went "it'll break > existing code", "what existing code"? "existing code" "but what > existing code?" "i dunno, just, er, code" "ok *how* will it break it?" > "i dunno, it just will"?
See below for a possible example. >> BTW, I am curious about how you do unit testing. The example that I used >> in my summary is a very common pattern but would break in cgi.escape >> changed it's semantics. What do you do instead? > > To be honest I'm not sure what *sort* of code people test this way. It > just doesn't seem appropriate at all for web page generating code. Well, there are dozens (hundreds?) of templating systems for Python. Here is a (simplified/modified) unit test for my company's system (yeah, we lifted some ideas from Django): test.html --------- <p>{foo | escape}</p> test.py ------- t = Template("test.html") t['foo'] = 'Brian -> "Hi!"' assert str(t) == '<p>Brian -> "Hi"</p>' So how would you test our template system? > Web > pages need to be manually viewed in web browsers, and validated, and > checked for accessibility. True. > Checking they're equal to a particular > string just seems bizarre (and where does that string come from > anyway?) Maybe, which is why I'm asking you how you do it. Some of our web applications contain 100s of script generated pages. Testing each one by hand after making a change would be completely impossible. So we use HTTP scripting for testing purposes i.e. send this request, grab the results, verify that the test in the element with id="username" equals "Brian Quinlan", etc. The test also validates that each page is well formed. We also view each page at some point but not every time a developer makes a change that might (i.e. everything) affect the entire system. Cheers, Brian -- http://mail.python.org/mailman/listinfo/python-list