test-fixture-issues

test-fixture issues. Note that test-fixture is a poshformat, has not been through the microformats process. test-fixture serves a purely functional purpose for microformats test-suite work.

open issue! 2012-09-10 raised by Tantek Çelik

• Upgrade test-fixture to use microformats2 class names, e.g.:
  • h-x-test-fixture
  • h-x-assertion
  • ... etc.
• replace 'output' property with separate
  • 'p-x-mime' property (on a <pre> element) for vcf/ics output,
  • 'p-x-json' property (on <source lang=javascript> or div) for JSON output, and
  • 'e-x-xml' property for XML output (e.g. Atom).
• replace 'history' with 'p-x-history' and 'h-entry' for sub-structure.

open issue! 2009-07-06 raised by Tantek Çelik

• Output should be specifiable inline, rather than having to be external. Currently the output appears to require linking to an external file, while it can be much more convenient as a test author to specify the output in the test case file itself. In fact, "output" on anything other than a hyperlink should mean that the output is inline in the test case page, rather than in a separate resource. For example: value-dt-test-YYYY-MM-DD--HH-MM. Tantek 18:51, 6 July 2009 (UTC)
  • …

open issue! 2009-06-26 raised by BenWard

• Output type could be implied from a/@type rather than explicit?. Currently the output type is explicit in a type attribute, but either the output could just be taken from the anchor, or if it is duplicated visibly, perhaps it should match the MIME type rather than using strings? e.g. &ltspan class="type">text/html</span>.
  • +1 I agree this could be simplified by taking the output type from the type attribute of an <a href class="output"> rather than making it explicit. However, I think the explicit visible one is a good one (per the visibility principle), and thus we should keep it, make it optional, and fall back to the type attribute. Tantek 18:51, 6 July 2009 (UTC)
  • …

open issue! 2009-06-26 raised by BenWard

• Represent history of changes using hAtom rather than hCalendar. It strikes me that hAtom would be a more appropriate format for a changelog than hCalendar.
  • +1 agreed. Let's use hAtom for this, not hCalendar. Tantek 18:51, 6 July 2009 (UTC)
  • …

open issue! 2009-06-26 raised by BenWard

• Consider separating *Unit asserts from custom asserts. Although the normalisation of Geo and Dates is a very useful enhancement, they may not be essential (since ISO dates can be compared somewhat reliably as strings, and co-ordinates compared to the same precision as they appear in the source). This seems desirable for simple conversion into something like JUnit, without being dependent on additional functions.
  • Some parsers discard the ISO string in favor of another date representation (e.g. MoFo, Sumo). When testing these parsers, equality assertions for dates would require some additional logic to compare the parsed value to the asserted value. For parsers that output dates as a generic data type (e.g. as an integer containing a UNIX timestamp) detecting when to apply this date-specific logic would be non-trivial and could require knowledge of which µf fields should contain dates, undermining the design goal of self contained tests. Keeping a separate equality assertion method for dates could therefore reduce complexity overall. - GeorgeBrock 16:43, 1 July 2009 (UTC)
    • If you had, for example isEqualTo("2009-07-06T22:29:00-0800") on a property that the parser treats internally as a date, surely it will also parse the 2009-07-06T22:29:00-0800 through the same algorithm? I see it might be good to have this explicit, but it also seems to be strongly implicit that where a parser transforms a data-type from the original string, the same transformation will occur before a comparison is made. --BenWard 05:31, 7 July 2009 (UTC)