Difference between revisions of "test-fixture-issues"

From Microformats Wiki
Jump to navigation Jump to search
(Documented test-fixture suggestions we might consider before putting into production.)
 
(Possible benefits of retaining a separate assertion method for dates)
Line 21: Line 21:
 
<div class="entry-content discussion issues">
 
<div class="entry-content discussion issues">
 
* <strong class="entry-title">Consider separating *Unit asserts from custom asserts</strong>. 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.
 
* <strong class="entry-title">Consider separating *Unit asserts from custom asserts</strong>. 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. [http://mofo.rubyforge.org/ MoFo], [http://github.com/danwrong/sumo/ 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. - [[User:GeorgeBrock|GeorgeBrock]] 16:43, 1 July 2009 (UTC)
 
** …
 
** …
 
</div>
 
</div>
 
</div>
 
</div>

Revision as of 16:43, 1 July 2009

Issues against test-fixture. Note that this poshformat has not been through the microformats process and serves a funcational purpose for the microformats test suites work.

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>.

open issue! 2009-06-26 raised by BenWard

  • Represent history of changes using hAtom rather than hCalendar. It strikes me that hAtom 0.1 would be a more appropriate format for a changelog than hCalendar.

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)