URL serialization tests are driven by an algorithm, not data

[domenic]

This seems bad:

https://github.com/w3c/web-platform-tests/blob/12d3e15e5ecae695e1216c358d613705fbff6b68/url/urltestparser.js#L18-L26

Instead of writing an algorithm to assemble href, and testing against it, instead the href strings should be in the test data. Otherwise, the test harness has to sync with https://url.spec.whatwg.org/#concept-url-serializer

Related: whatwg/url#52 jsdom/whatwg-url#22

[annevk]

I don't see why this is bad. What problem is being solved by duplicating data? To make it easier to write a test harness?

[domenic]

"Tests should not contain logic" is the guiding principle. There are bad bugs in the current test href-assembly algorithm that are hiding bugs in implementations. It is better for the tests to be straightforward and easily-checkable, without potentially-buggy logic.

This is a general principle that is not always easy to apply, especially for a system as complicated as web platform tests. But in this case, it's very easy to apply, and avoid the pitfalls of tests-that-themselves-need-tests because they are doing things that are too complicated.

[annevk]

My main issue here is that it makes parsing tests much harder to write and we don't get much of a win. And we don't have that many parsing tests yet. I think e.g., for the HTML parser tests it helps that there is a custom simple format to write tests in. But maybe that's not true and a file ten times the size is still okay...

[domenic]

How does it make the tests harder to write? It certainly makes them easier to read.

If you're worried about the number of tests, we plan to contribute a lot more of them from jsdom/whatwg-url, using code coverage tools. The changes in #2436 were the first step in that.

[annevk]

More boilerplate, but okay. Since you're doing the work you get to decide. I obviously haven't done much on this front lately.

[SimonSapin]

This can be closed since #2436, right?

[domenic]

Yep!