Simon Brunning wrote: > On 26 Sep 2006 15:53:46 GMT, Jon Ribbens <[EMAIL PROTECTED]> wrote: > > 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. Web > > pages need to be manually viewed in web browsers, and validated, and > > checked for accessibility. Checking they're equal to a particular > > string just seems bizarre (and where does that string come from > > anyway?) > > The kind of acceptance testing that you are talking about is very > important, but you can't automate "Does it look OK in a browser?". > Unit tests suitable for automation don't have anything to work with > *but* the generated HTML.
I can understand the disbelief that a straight string comparison involving HTML might be a robust enough test for the output of a Web application, given that potentially many equivalent representations of some piece of text may exist, and especially given the typical unpredictability of many XML-based solutions with respect to things like whitespace, encodings, entity usage, and the like. On the other hand, the initial complaint in this thread, whilst reasonable in the context of some ideal function for "quoting stuff in HTML pages", is somewhat inappropriate in the context of modifying an existing, mature function which is now in ubiquitous usage. In order to minimise the unpredictability of solutions, we should avoid making fundamental changes especially at the lower levels of such solutions. I can't remember whether I have any code using cgi.escape, although since I usually use XML APIs rather than writing HTML manually, I suspect that I haven't. Nevertheless, the breakage potentially caused by even one call site involving a modified variant of cgi.escape would be enough for most people to consider reimplementing the semantics of the existing function, thus undermining the inclusion of such a function in the standard library in the first place. Paul -- http://mail.python.org/mailman/listinfo/python-list
