test-fixture-issues - Revision history

Tantek: upgrade test-fixture to microformats2

2012-09-10T16:59:17Z

upgrade test-fixture to microformats2

← Older revision		Revision as of 16:59, 10 September 2012
Line 1:		Line 1:
	[[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.		[[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.

			<div class="h-entry hentry">
			{{OpenIssue}} <span class="entry-summary"><time class="dt-published published">2012-09-10</time> raised by <span class="p-author author h-card">[[User:Tantek\|Tantek Çelik]]</span></span>
			<div class="e-content entry-content discussion issues">
			* 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 <code><pre></code> element) for vcf/ics output,
			** 'p-x-json' property (on <code><source lang=javascript></code> 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.
			</div>
			</div>

	<div class="hentry">		<div class="hentry">

BenWard: Follow-up on the isISODate() special asserts

2009-07-07T05:31:45Z

Follow-up on the isISODate() special asserts

← Older revision		Revision as of 05:31, 7 July 2009
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>

Tantek: 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

2009-07-06T18:51:34Z

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

← Older revision		Revision as of 18:51, 6 July 2009
Line 1:		Line 1:
	~~Issues against~~ test-fixture. Note that ~~this~~ poshformat has not been through the microformats process ~~and~~ serves a ~~funcational~~ purpose for ~~the~~ [[test-suite]] work.		[[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.

			<div class="hentry">
			{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-07-06</span> raised by <span class="fn">[[User:Tantek\|Tantek Çelik]]</span></span>
			<div class="entry-content discussion issues">
			* <strong class="entry-title">Output should be specifiable inline, rather than having to be external</strong>. 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]]. [[User:Tantek\|Tantek]] 18:51, 6 July 2009 (UTC)
			** …
			</div>
			</div>

	<div class="hentry">		<div class="hentry">
Line 5:		Line 13:
	<div class="entry-content discussion issues">		<div class="entry-content discussion issues">
	* <strong class="entry-title">Output type could be implied from <code>a/@type</code> rather than explicit?</strong>. Currently the output type is explicit in a <code>type</code> 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. <code>&ltspan class="type">text/html</span></code>.		* <strong class="entry-title">Output type could be implied from <code>a/@type</code> rather than explicit?</strong>. Currently the output type is explicit in a <code>type</code> 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. <code>&ltspan class="type">text/html</span></code>.
			** +1 I agree this could be simplified by taking the output type from the <code>type</code> 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 <code>type</code> attribute. [[User:Tantek\|Tantek]] 18:51, 6 July 2009 (UTC)
	** …		** …
	</div>		</div>
Line 13:		Line 22:
	<div class="entry-content discussion issues">		<div class="entry-content discussion issues">
	* <strong class="entry-title">Represent history of changes using hAtom rather than hCalendar</strong>. It strikes me that [[hAtom]] would be a more appropriate format for a changelog than hCalendar.		* <strong class="entry-title">Represent history of changes using hAtom rather than hCalendar</strong>. 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. [[User:Tantek\|Tantek]] 18:51, 6 July 2009 (UTC)
	** …		** …
	</div>		</div>

GeorgeBrock: Possible benefits of retaining a separate assertion method for dates

2009-07-01T16:43:05Z

Possible benefits of retaining a separate assertion method for dates

← Older revision		Revision as of 16:43, 1 July 2009
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>

BenWard: Documented test-fixture suggestions we might consider before putting into production.

2009-06-29T21:25:49Z

Documented test-fixture suggestions we might consider before putting into production.

New page

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

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-06-26</span> raised by <span class="fn">[[User:BenWard|BenWard]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Output type could be implied from <code>a/@type</code> rather than explicit?</strong>. Currently the output type is explicit in a <code>type</code> 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. <code>&ltspan class="type">text/html</span></code>.
** …
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-06-26</span> raised by <span class="fn">[[User:BenWard|BenWard]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Represent history of changes using hAtom rather than hCalendar</strong>. It strikes me that [[hAtom]] would be a more appropriate format for a changelog than hCalendar.
** …
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-06-26</span> raised by <span class="fn">[[User:BenWard|BenWard]]</span></span>
<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.
** …
</div>
</div>