To make easily testing without manual intervention possible, it would be
great if the ThriftTest clients actually checked the results of the RPC
calls, instead of just printing them to the console like C++/Java
currently do.
Also, it would be great if either all the functions from the ThriftTest
interface only returned a copy from their arguments (testMapMap and
testInsanity currently don't), or the return values were the same across
all implementations (e.g. by defining them as constants in
ThriftTest.thrift), so that these checks could also be active when doing
cross-language testing.
David
On 6/20/11 8:18 PM, Roger Meier wrote:
-----Ursprüngliche Nachricht-----
Von: Anthony Molinaro [mailto:antho...@alumni.caltech.edu]
Gesendet: Sonntag, 19. Juni 2011 21:17
An: dev@thrift.apache.org
Cc:<dev@thrift.apache.org>
Betreff: Re: AW: AW: Use rebar with erlang code?
From my perspective everything should be moved from test/erl to
lib/erl/test/
The test directory should only contain test definitions like the
ThriftTest.thrift
Doesn't that sort of make testing harder if the thrift files are in a
different
place from the tests? Also if cross language tests are ever implemented
where would you expect those to live?
I might suggest that pure unit tests (including thrift files for those
tests) live
in the lib/*/test directories but the test servers and clients for cross
language
testing continue to live in top level test directory (possibly with
something
which runs all combinations against each other).
-Anthony
From my perspective test/ is the directory that keeps all IDL files for
UnitTests, which will be used across languages.
e.g. the ThriftTest.thrift is used by several unit tests
I think it's much easier to build all the tests when they are part of the
usual build procedure of a specific language.
It's probably a bit difficult to keep test under test/ in sync with the
build process of the library,
that's why a propose to put all the tests in lib/<lang>/test/
The get a cross language test capability I suggest the following approach:
- The language specific build procedures should create an executable with
the name TestClient and TestServer
- They should be placed under test/<lang>/ or a shell script with the same
name calls corresponding Client or Server
- The test client and servers should have a unified set of arguments, so
that cross language tests could easily be automated, e.g.
roger@slave:~/software/thrift/thrift-trunk$ ./test/cpp/TestServer -h
Allowed options:
-h [ --help ] produce help message
--port arg (=9090) Port number to listen
--domain-socket arg Unix Domain Socket (e.g.
/tmp/ThriftTest.thrift)
--server-type arg (=simple) type of server, "simple", "thread-pool",
"threaded", or "nonblocking"
--transport arg (=buffered) transport: buffered, framed, http
--protocol arg (=binary) protocol: binary, json
--ssl Encrypted Transport
using SSL
--processor-events processor-events
-n [ --workers ] arg (=4) Number of thread pools workers. Only
valid for thread-pool server type
roger@slave:~/software/thrift/thrift-trunk$ ./test/cpp/TestClient -h
Allowed options:
-h [ --help ] produce help message
--host arg (=localhost) Host to connect
--port arg (=9090) Port number to connect
--domain-socket arg Domain Socket (e.g.
/tmp/ThriftTest.thrift), instead of host and port
--transport arg (=buffered) Transport: buffered, framed, http
--protocol arg (=binary) Protocol: binary, json
--ssl Encrypted Transport
using SSL
-n [ --testloops ] arg (=1) Number of Tests
-Roger
