[2/4] incubator-tinkerpop git commit: Minor point added to docs about testing implementations.

[ok...@apache.org]

Minor point added to docs about testing implementations.


Project: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/commit/66cde14b
Tree: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/tree/66cde14b
Diff: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/diff/66cde14b

Branch: refs/heads/neo4j-gremlin-apache
Commit: 66cde14bc86c3bd2f40ade561edc9a7397a082dc
Parents: 649de76
Author: Stephen Mallette <sp...@genoprime.com>
Authored: Thu May 28 12:26:51 2015 -0400
Committer: Stephen Mallette <sp...@genoprime.com>
Committed: Thu May 28 12:28:34 2015 -0400

----------------------------------------------------------------------
 docs/src/implementations.asciidoc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/66cde14b/docs/src/implementations.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/implementations.asciidoc b/docs/src/implementations.asciidoc
index eb643e3..e61fefb 100644
--- a/docs/src/implementations.asciidoc
+++ b/docs/src/implementations.asciidoc
@@ -319,7 +319,7 @@ public class XXXGroovyProcessComputerTest {}
 
 The above set of tests represent the minimum test suite set to implement.  There are other "integration" and "performance" tests that should be considered optional.  Implementing those tests requires the same pattern as shown above.
 
-IMPORTANT: It is as important to look at "ignored" tests as it is to look at ones that fail.  The `gremlin-test` suite utilizes the `Feature` implementation exposed by the `Graph` to determine which tests to execute.  If a test utilizes features that are not supported by the graph, it will ignore them.  While that may be fine, implementers should validate that the ignored tests are appropriately bypassed and that there are no mistakes in their feature definitions.
+IMPORTANT: It is as important to look at "ignored" tests as it is to look at ones that fail.  The `gremlin-test` suite utilizes the `Feature` implementation exposed by the `Graph` to determine which tests to execute.  If a test utilizes features that are not supported by the graph, it will ignore them.  While that may be fine, implementers should validate that the ignored tests are appropriately bypassed and that there are no mistakes in their feature definitions.  Moreover, implementers should consider filling gaps in their own test suites, especially when IO-related tests are being ignored.
 
 The only test-class that requires any code investment is the `GraphProvider` implementation class. This class is a used by the test suite to construct `Graph` configurations and instances and provides information about the vendor's implementation itself.  In most cases, it is best to simply extend `AbstractGraphProvider` as it provides many default implementations of the `GraphProvider` interface.
 
@@ -377,7 +377,7 @@ The annotation above shows that the name of each parameterized test will be pref
 
 These annotations help provide users a level of transparency into test suite compliance (via the xref:describe-graph[describeGraph()] utility function). It also allows implementers to have a lot of flexibility in terms of how they wish to support TinkerPop.  For example, maybe there is a single test case that prevents an implementer from claiming support of a `Feature`.  The implementer could choose to either not support the `Feature` or to support it but "opt-out" of the test with a "reason" as to why so that users understand the limitation.
 
-IMPORTANT: Before using `OptOut` be sure that the reason for using it is sound and it is more of a last resort.  It is possible that a test from the suite is doesn't properly represent the expectations of a feature, is too broad or narrow for the semantics it is trying to enforce or simply contains a bug.  Please consider raising issues in the developer mailing list with such concerns before assuming `OptOut` is the only answer.
+IMPORTANT: Before using `OptOut` be sure that the reason for using it is sound and it is more of a last resort.  It is possible that a test from the suite doesn't properly represent the expectations of a feature, is too broad or narrow for the semantics it is trying to enforce or simply contains a bug.  Please consider raising issues in the developer mailing list with such concerns before assuming `OptOut` is the only answer.
 
 IMPORTANT: There are no tests that specifically validate complete compliance with Gremlin Server.  Generally speaking, a `Graph` that passes the full Test Suite, should be compliant with Gremlin Server.  The one area where problems can occur is in serialization.  Always ensure that IO is properly implemented, that custom serializers are tested fully and ultimately integration test the `Graph` with an actual Gremlin Server instance.