devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <>
Subject Re: Testing classifiers written in different languages
Date Fri, 09 Jan 2015 14:00:22 GMT
I'm already thinking about tests [0]. All clients would share the same test suite.

I'm working on the pattern spec now [1]. When that's ready, it should be clear how this will
all come together. This spec is like 80% of 2.0. It's in a very rough and early stage right
now, so it may be confusing. Going to put some more time on it today and maybe move it to
the wiki.



<div>-------- Original message --------</div><div>From: Werner Keil <>
</div><div>Date:01/09/2015  5:39 AM  (GMT-05:00) </div><div>To:
</div><div>Cc:  </div><div>Subject: Re: Testing classifiers written
in different languages </div><div>


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
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.


On Fri, Jan 9, 2015 at 9:59 AM, Bertrand Delacretaz <>

> 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]
> (*) 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.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message