- 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)
- …
test-fixture-issues: Difference between revisions
Jump to navigation
Jump to search
(agree with a couple of issues, add a new issue about output should be permissible inline in the test case, edit page intro a bit) |
(Follow-up on the isISODate() special asserts) |
||
| Line 32: | Line 32: | ||
* <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) | ** 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) | ||
** | *** If you had, for example <code>isEqualTo("2009-07-06T22:29:00-0800")</code> on a property that the parser treats internally as a date, surely it will also parse the <code>2009-07-06T22:29:00-0800</code> 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. --[[User:BenWard|BenWard]] 05:31, 7 July 2009 (UTC) | ||
</div> | </div> | ||
</div> | </div> | ||
Revision as of 05:31, 7 July 2009
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!
open issue!
- Output type could be implied from
a/@typerather than explicit?. Currently the output type is explicit in atypeattribute, 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.<span class="type">text/html</span>.- +1 I agree this could be simplified by taking the output type from the
typeattribute 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 thetypeattribute. Tantek 18:51, 6 July 2009 (UTC) - …
- +1 I agree this could be simplified by taking the output type from the
open issue!
open issue!
- 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 the2009-07-06T22:29:00-0800through 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)
- If you had, for example
- 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)