RE: Testing API options

On Saturday, August 24, 2013 3:07 AM, Gregg Kellogg wrote:
>> On Aug 23, 2013, at 12:42 PM, Dave Longley wrote:
>>> On 08/23/2013 04:51 AM, Markus Lanthaler wrote:
>>>> I think that would simplify the implementation of test runners as well
as
>>>> make the test manifests more concise.
>>
>> +1
>
> Okay, there's few enough options that defining a term for each isn't
> too much of a problem.
>
> I updated the test-suite context at
<http://json-ld.org/test-suite/context.jsonld>.
> I also created two vocabulary definitions (Turtle and JSON-LD) at
vocab.ttl
> and vocab.jsonld.

Awesome!


> As the vocabulary is referenced using
> <http://json-ld.org/test-suite/vocab#> it would be good form to have some
> content-negotiation rewrite rules in the .htaccess file; I attempted to
> create such rewrite rules, but it doesn't seem to be properly detecting
> text/ttl and application/ld+json; perhaps someone more familiar with
Apache
> can take a look. Right now, it returns a stub HTML doccument, were we can
> document using HTML+RDFa.

It's a bit difficult without knowing how Apache is configured but I may give
it a try the next days if no one else does it in the meantime.

[...]
> We should probably just say that in test documentation that the
> processingMode json-ld-1.0 is assumed to be present for every test.

Yes.


[...]
> Probably the way to do it is to define the behavior of a callback that
> must be used to respond to such a callback. It should take into account
> arguments and options passed to the callback so that they can be
> reflected back in some meaningful way to get the results.

Fortunately there's just a single parameter (and no options): the URL of the
remote document/context.


> This sounds like a separate test manifest just to test the callback
> behavior.

Yes, it is clearly an API test and not an algorithm test.


> Maybe this also includes catching an exception raised in the callback
> handler to generate the appropriate exception in an error manifest.

There are no exceptions. The callback returns a promise with an error code
in case of a failure. We shouldn't test the callback directly though
(because it's user supplied) but whether the API does the right thing in
response to the various callback return values. There shouldn't be too many.


--
Markus Lanthaler
@markuslanthaler

Received on Saturday, 24 August 2013 10:46:14 UTC