2007/5/31, Sam Ruby: > Thomas Broyer wrote: > > 2007/5/31, Sam Ruby: > >> I believe I found an error in test_serialize that causes four tests to > >> be marked as passing when the serialized result obtained is not in the > >> list of expected results. > > > > No, actually, that was supposed to be a feature ;-) > > > > Considering that serializing without omitting option tags has no bug > > (which should be proved by other tests in core.test for example), this > > allows us to only include the expected possible results *with optional > > tags omitted* in the test's "expected" list. > > I would buy that, if that were what the test code actually did. But I > found a bug where (previously) if the value had a single quote in it but > no double quote in it, and use_best_quote char was set, it would chose > to use single quotes instead of double quotes.[1] > > It bothered me that this wasn't caught in the unit tests, but when I > looked closer, there were tests for this.
Actually no, there weren't.
I've just fixed core.test to take into account that
use_best_quote_char defaults to true (i.e. that {"title", "foo\"bar"}
will now serialize as title='foo"bar' rather than
title="foo"bar")
> So I looked closer. Here's what the test code looked like:
>
> > if result not in expected:
> > if options.get("omit_optional_tags", True):
> > options["omit_optional_tags"] = False
> > self.assertEquals(self.serialize_html(input, options), result)
> > else:
> > result = self.serialize_html(input, options)
>
> Paraphrased, this says "if the result is not expected, try again with
> omit_optional_tags=false and verify that you get the SAME unexpected result"
>
> Is this what you really intended?
Well... for optionaltags.test, yes, but I must admit that it's totally
wrong for other tests...
> Changing the test code to say "if the result is not expected, try again
> with omit_optional_tags=false and see if the result you obtain on the
> second attempt is in the expected list" produces 18 failures.
...because the tests' "expected" list doesn't contain that particular
expected value...
If your revert changes made to optionaltags.test in rev 627, they all
pass. There's only one test failing, in options.test, still due to the
new use_best_quote_char option defaulting to true.
I've no real problem with reverting 627, just that it's not easy to
test whether the "optional tags filter" is optimized for
compactness...
...or maybe we should add an "alternate_expected" key/value pair to
the tests. "expected" then meaning "optimized expected results
list"... I'd prefer such an approach... any thoughts?
--
Thomas Broyer
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"html5lib-discuss" group.
To post to this group, send email to html5lib-discuss@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4