Btw. regardless of whether this may now have to be outside Apache or not,
there were extensive tests by W3C DDR for compatibility:
http://www.w3.org/2005/MWI/DDWG/drafts/api/test-report.html

Those who wish to work on a Perl implementation please have a look at the
still working attachment on top of that page. It contains a (seemingly
compatible) Perl implementation of W3C Simple DDR.

Werner



On Fri, Jan 9, 2015 at 11:39 AM, Werner Keil <[email protected]> wrote:

> Bertrand/all,
>
> +1
>
> I moved the test data to /contrib because there is no mandatory
> dependency, it simply gathers myriads of UA strings as it seems. A small
> subset comes with the classifier JUnit tests while the W3C DDR
> implementation contains a small test equivalent of devicemap-data for test
> purposes and some UA signatures.
> Testing against the actual devicemap-data if any other tests do that (at
> least that URL in the classifier tests sounds like it) is strictly speaking
> already an "integration test" and for something like that or a "W3C
> compatibility test kit" (similar to what JCP standards do) we should have
> separate tests, not mix them with unit tests only testing the internals of
> a library or client.
>
> Werner
>
>
>
> On Fri, Jan 9, 2015 at 9:59 AM, Bertrand Delacretaz <
> [email protected]> wrote:
>
>> Hi,
>>
>> Considering the discussion on multiple classifier (*) implementations,
>> I just wanted to point to [1] which (once suitably updated) might be
>> useful for testing clients written in different languages to verify
>> that they return the same results.
>>
>> The idea of that file was to define a language-independent test data
>> set, each line contains a user-agent and a set of expected properties
>> output by the classifier.
>>
>> -Bertrand
>>
>> [1]
>> https://svn.apache.org/repos/asf/devicemap/trunk/contrib/test-data/src/main/resources/test-data/dmap_20130522.txt
>>
>> (*) BTW I personally prefer using the more specific "classifier" term
>> over "client" which is quite generic and can be confusing if we start
>> having both server-side and client-side implementations.
>>
>
>

Reply via email to