Updated test case document - in progress
authorT Dong Huynh <tdh@ecs.soton.ac.uk>
Tue, 04 Dec 2012 09:54:25 +0000
changeset 5278 119abeec0fa2
parent 5277 fd495d554ff6
child 5279 0aee3367148e
Updated test case document - in progress
testcases/process.html
--- a/testcases/process.html	Mon Dec 03 22:12:13 2012 -0800
+++ b/testcases/process.html	Tue Dec 04 09:54:25 2012 +0000
@@ -99,27 +99,38 @@
 
 <h2>Report Your Validator</h2>
 
-<p class="note">TODO: Introduction about the testing and reporting process.</p>
+<p>The support for constraints from [[PROV-CONSTRAINTS]] in implementations cannot be
+determined as straightforward as with the features from the other PROV documents as
+they are, in many cases, interrelated. Sometimes, it is indeed required to consider a
+number of constraints together to determine the validity of a PROV document.
+Therefore, in order to facility reporting implementations of PROV-CONSTRAINTS, we provide
+test cases to assist with determining the level of support of a PROV-CONSTRAINTS
+implementation.</p>
+
+<p>A test case for PROV-CONSTRAINTS is a PROV document that contains either valid or
+invalid PROV statements, and implementers of PROV-CONSTRAINTS are asked to determine its
+validity (as specified in [[PROV-CONSTRAINTS]]). The test cases are specially designed to
+cover a small set of constraints (called unit test cases, see <a href="#unit-test-cases" class="sectionRef">Section 2.1</a>) or to exercise a subset of PROV statements. By
+successfully determining the validity of such a test case, an implementation indirectly
+demonstrates its support for the PROV feature(s) covered by the test case.
+</p>
 
 <section id="testcase-identifier">
 
 <h3>Test cases</h3>
 
-<p>The test cases for PROV-CONSTRAINTS (see <a href="#table-unit-test-cases">Table 2</a>) can be downloaded from <a
-href="http://dvcs.w3.org/hg/prov/raw-file/default/testcases/constraints/">http://dvcs.w3.org/hg/prov/raw-file/default/testcases/constraints/</a></p>
 <p>
-  Each test case has an identifier, e.g. <strong>association2-FAIL-c50</strong>.
-  In order to facilitate the testing process, the identifier
-  also indicates whether the test case should be successfully validated (i.e. <b>PASS</b>)
-  or not (i.e. <b>FAIL</b>). In addition, in case of the latter, we also include the
-  numberings of the constraints that we expect to cause the test case to fail validation,
-  e.g. <a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#typing"><b>c50</b></a>. 
+Each test case is given an identifier, e.g. <b>ordering-derivation1-PASS-c42</b>, which
+indicates whether the test case should be successfully validated (i.e. <b>PASS</b>)
+or not (i.e. <b>FAIL</b>). In addition, a test case's identifier also includes the
+numberings of the constraints that it covers at the end.
+e.g. <a class="externalDFN" href="http://www.w3.org/TR/2012/CR-prov-constraints-20121211/#derivation-generation-generation-ordering"><b>c42</b></a>. 
 </p>
 
 <p>The provenance document for each test case will be provided in the following representations:</p>
 
 <table class="simple">
-  <caption>Table 1. File representations provided for test cases.</caption>
+  <caption>Table 1. File representations provided for every test cases.</caption>
   <tr>
     <th>Representation</th>
     <th>File extension</th>
@@ -142,16 +153,14 @@
   </tr>
 </table>
 
-
-
-<p>For example, the available files for the test case <strong>association2-FAIL-c50</strong>
-are: <strong>association2-FAIL-c50.provx</strong>, <strong>association2-FAIL-c50.ttl</strong>,
-and <strong>association2-FAIL-c50.provn</strong>. Although all the thee representations are
-provided for each test case, your implementation will only need to validate one
-representation (out of the three) in order to test a case.</p>
+<p>For example, the available files for the test case <b>ordering-derivation1-PASS-c42</b>
+are: <b>ordering-derivation1-PASS-c42.ttl</b>, <b>ordering-derivation1-PASS-c42.provn</b>,
+and <b>ordering-derivation1-PASS-c42.provx</b>. Although all the thee representations are
+provided for every test case, your implementation will only need to validate one
+representation (out of the three) in order to report the result for one.</p>
 
 <p>For your convenience, the download links for all the available test cases
-(see <a href="#test-cases" class="sectionRef">Section 2</a>)
+(see <a href="#test-case-catalogues" class="sectionRef">Section 2</a>)
 for each representation are resectively provided in the following text files:
 <a href="rdf-tests.txt">rdf-tests.txt</a>, <a href="provn-tests.txt">provn-tests.txt</a>,
 and <a href="xml-tests.txt">xml-tests.txt</a>. Please note that, all though we provide three different representations, you only need to validate one represetation per each test case.</p>
@@ -171,12 +180,12 @@
 in either of the files.</p>
 
 <p>For example, if a validator can <strong>only</strong> process the three test cases
-<b>ordering-derivation1-PASS</b>, <b>ordering-derivation2-FAIL-c42</b>, and <b>ordering-derivation3-PASS</b>, we
+<b>ordering-derivation1-PASS-c42</b>, <b>ordering-derivation2-FAIL-c42</b>, and <b>ordering-derivation3-PASS-c41-c42</b>, we
 expect the result files's contents to be similar to the below.</p>
 <pre class="example">
 pass.txt:
-	ordering-derivation1-PASS
-	ordering-derivation3-PASS
+	ordering-derivation1-PASS-c42
+	ordering-derivation3-PASS-c41-c42
 	
 fail.txt:
 	ordering-derivation2-FAIL-c42
@@ -196,7 +205,7 @@
 
 <section>
 
-<h2>Test Cases</h2>
+<h2>Test Case Catalogues</h2>
 
 <p class="note">TODO: Introduction about the different types of test cases and how to get them.</p>