| [corona-dev] Client-server JUnit tests issues |
|
Hi There are some open issues concerning the design of tests of
client-server interaction: 1. Should we assume that all client tests require server
availability? If yes, this makes client tests more difficult to run even in
simplest cases. Further, JUnit automated tests can only be run if the full
build is made. If no, how to distinguish tests that concern client (only), client-server
(both) or server (only). Running a test that concern client and server is
something like integration test. It is not possible to design JUnit tests in such way that
both client and server execute tests simultaneously. They can get out of synch
very easily. Therefore, the currently proposed test configuration looks
like this: Client tests cooperating with server: a) server is started in the standard mode b) client is started in "debug" mode, i.e. it
executes JUnit tests that communicate with the server c) client behavior is recorded. Server tests cooperating with client: a) client is started in the standard mode b) server is started in "debug" mode, i.e. it
executes JUnit tests that communicate with the client c) server behavior is recorded. All this can be done automatically from the ant script
(using parallel and exec), but there is no debug information on the
"other" side of the test. Is it enough to test server without client interaction. Theoretically,
we don't care what clients are connected to the server. 2. How to stop server after finishing client tests? If we don't want to use "kill" or timeout
"kill", the server should close after receiving some kind of
notification - either it should receive "event of close" from the
client or poll for a special file in the file system (the file can be created
by ant after finishing JUnit client tests). Any other ideas? In any case minor
modifications to server code are necessary. The problem equally applies to stopping client after server
tests. 3. What about config.ini files - should they be included in the
final build for client and server? It is very uncommon to modify config.ini of the Eclipse
platform, but a user may miss the point of copying the files to his Eclipse. The
existence of config.ini in the build influences the preparation of tests, although
any solution is fine from this point of view. 4. JUnit server tests are required to check if the build process
really works. Currently, the build script includes client tests. All client-server and server issues are commented out and
waiting for the final configuration. Pawel |