sshyran / genxdm

Automatically exported from code.google.com/p/genxdm
0 stars 0 forks source link

Improve bridgetest #17

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
bridgetest is best described as "hit or miss," I think. It is at best difficult 
to determine which parts of the contract are covered, but better described as 
"sufficiently challenging to be practically impossible."

We should have a clear, contract-based test suite. For instance, we ought to 
have a "ProcessingContextTestBase" which checks all the values of arguments and 
return values for each method. It should have names like: testGetModel() and 
testNewCursor(). Each such test should fully test the preconditions and 
postconditions of the methods called. There may also be tests of consistency: 
for instance, you can ask a processing context whether it supports the "type" 
feature, and you can ask it for a typed context. If it says "yes" to type, then 
it must return a typed context; if it returns a typed context from 
getTypedContext(), then it should say yes to type.

Some of the current test framework may be salvageable, but the names of tests 
make one want to scream (test0001() tests exactly what now?).

This is marked as "defect" rather than enhancement because some parts of the 
untyped API (for instance) are only exercised in apparently-unrelated tests 
marked as part of the typed API. This is understandable, in a way (the 
distinction didn't used to exist), but ... unacceptable in another way. In 
refactoring Cx, the TypedValue test turned out to contain a test of the 
following-sibling axis postconditions: an attempt to get the following sibling 
axis for an attribute or namespace must return null. WTF does that have to do 
with typed values?

Plan: for each interface, create a new test, in a new package in bridgetest 
(using otherwise the same techniques), naming tests for each method in the 
interface (ModelTestBase.testGetLocalName(), 
ModelTestBase.testGetFollowingSibling()). At the top of each file, list the 
methods in the interface, in a comment, and describe the contract for each. 
Note that a certain amount of the information thus generated probably ought to 
be in the javadoc; that may be a "next step." Start with core interfaces: 
ProcessingContext, FragmentBuilder, Model. Note: we may also introduce 
test-only interfaces (for instance: for creating a tree from an XML file, 
parsing, native-style) to avoid "accidentally" testing things that we should 
not be focussed on.

Original issue reported on code.google.com by aale...@gmail.com on 12 Oct 2010 at 4:36

GoogleCodeExporter commented 8 years ago
Okay. Started.

Original comment by aale...@gmail.com on 12 Oct 2010 at 4:36

GoogleCodeExporter commented 8 years ago
Okay.  The next checkin is going to have all of the current (remarkably 
ill-defined) bridgetest code moved into a new module, called legacytest.  That 
new module will begin life deprecated.  Bridgetest will get some initial 
checkins of the new-style stuff.

The new test base classes must provide equivalent coverage to the existing ones 
(which is certainly going to be hard to judge).  Basically: don't worry about 
the typed stuff yet (we need to finish adding tests in API/core anyway), but do 
have complete contract coverage for all the interfaces defined or referenced in 
base and base/mutable.

Original comment by aale...@gmail.com on 15 Dec 2010 at 6:58

GoogleCodeExporter commented 8 years ago
Move the priority up.  This seems to be doing a fine job of uncovering problems 
and provoking improvements, so let's agree that it's higher priority.  Also 
give it a clear milestone.

Original comment by aale...@gmail.com on 16 Dec 2010 at 9:15

GoogleCodeExporter commented 8 years ago
Bridgetest is in adequate condition for conformance testing, although it 
contains a bunch of TODO-s, and only for untyped and mutable APIs.

I'm marking this as blocked on 43, now, because we need the typed API to be 
stabilized before we can add typed testing.

Original comment by aale...@gmail.com on 31 Mar 2011 at 5:18

GoogleCodeExporter commented 8 years ago
43 is resolved, and I've just now resolved 60, which simplifies the structure 
of the tests needed somewhat (separating the functions of the typed context 
from the schema cache).  So we're moving ahead, now, on implementing testing 
for the typed API.

Original comment by aale...@gmail.com on 12 Oct 2011 at 6:48

GoogleCodeExporter commented 8 years ago
Should also improve tests to cover 
http://code.google.com/p/genxdm/issues/detail?id=66

Original comment by eric%tib...@gtempaccount.com on 30 Jul 2012 at 8:53

GoogleCodeExporter commented 8 years ago
Won't be completed in 1.0. Defer to 1.1

Original comment by aale...@gmail.com on 24 Oct 2013 at 5:18