Thomas Broyer wrote: >> Author: sa3ruby >> Date: Thu Jul 26 06:43:29 2007 >> New Revision: 919 >> >> Modified: >> trunk/python/tests/test_formfiller.py >> trunk/python/tests/test_whitespace_filter.py >> >> Log: >> Add the new test suites to runtest. >> Current status: FAILED (failures=17, errors=4) > > The 4 errors are NotImplementError in the (experimental) formfiller filter. > > 2 failures were serializer tests for the "strip_whitespace" option, > after I slightly changed the behavior of the whitespace-stripper > filter (was eating too much whitespace; now produces a bit less > optimized output but at least equivalent to the input -as long as you > don't use the CSS whitespace property-) > > The remaining failures are a "conflict": rev 870 change the tests for > name-less doctypes to be serialized as <!DOCTYPE>, and then rev 908 > changed the tests back to <!DOCTYPE > (note the space), without > touching at the python or ruby implementations, so now they're > failing. > I think we should just rollback changeset 870 (how about the ruby > implementation?): this space causes no harm as it's only there for > unit tests. > > What do you think?
I realize that this doesn't directly answer your question, but what I think is that the tests should reflect how we expect the software to behave TODAY. If there are things that we would like to see behave different in the future, the tests can be coded and commented out with # TODO or # XXX or the like. Why? Because I see unit tests as a way of enabling myself and others to make changes that we think won't affect other behaviors by enabling us to verify that such is the case. This means that if a given function is NotImplemented at the moment at least, then the expected result should be NotImplemented. If a space (or lack thereof) causes no harm in <!DOCTYPE>s, then lets just pick to either always include it or always exclude it, and then make all the code consistent. Finally, as to the Ruby implementation, ideally it too would always be in synch. And I, for one, appreciate your starting to make changes in both code bases. But if it lags slightly, I will from time to time take a look at errors and attempt to fix them, but only when the Python tests are passing. At such times, my job is fairly easy: I have a test case and a reference implementation to consult. When the test case and the reference implementation disagree, the job becomes considerably harder. - Sam Ruby --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "html5lib-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/html5lib-discuss?hl=en-GB -~----------~----~----~----~------~----~------~--~---
