|
| 1 | +# ReactiveSocket TCK Drivers |
| 2 | + |
| 3 | +This is meant to be used in conjunction with the TCK at [reactivesocket-tck](https://github.com/ReactiveSocket/reactivesocket-tck) |
| 4 | + |
| 5 | +## Basic Idea and Organization |
| 6 | + |
| 7 | +The philosophy behind the TCK is that it should allow any implementation of ReactiveSocket to verify itself against any other |
| 8 | +implementation. In order to provide a truly polyglot solution, we determined that the best way to do so was to provide a central |
| 9 | +TCK repository with only the code that generates the intermediate script, and then leave it up to implementers to create the |
| 10 | +drivers for their own implementation. The script was created specifically to be easy to parse and implement drivers for, |
| 11 | +and this Java driver is the first driver to be created as the Java implementation of ReactiveSockets is the most mature at |
| 12 | +the time. |
| 13 | + |
| 14 | +The driver is organized with a simple structure. On both the client and server drivers, we have the main driver class that |
| 15 | +do an intial parse of the script files. On the server side, this process basically constructs dynamic request handlers where |
| 16 | +every time a request is received, the appropriate behavior is searched up and is passed to a ParseMarble object, which is run |
| 17 | +on its own thread and is used to parse through a marble diagram and enact it's behavior. On the client side, the main driver |
| 18 | +class splits up each test into it's own individual lines, and then runs each test synchronously in its own thread. Support |
| 19 | +for concurrent behavior can easily be added later. |
| 20 | + |
| 21 | +On the client side, for the most part, each test thread just parses through each line of the test in order, synchronously and enacts its |
| 22 | +behavior on our TestSubscriber, a special subscriber that we can use to verify that certain things have happened. `await` calls |
| 23 | +should block the main test thread, and the test should fail if a single assert fails. |
| 24 | + |
| 25 | +Things get trickier with channel tests, because the client and server need to have the same behavior. In channel tests on both |
| 26 | +sides, the driver creates a ParseChannel object, which parses through the contents of a channel tests and handles receiving |
| 27 | +and sending data. We use the ParseMarble object to handle sending data. Here, we have one thread that continuously runs `parse()`, |
| 28 | +and other threads that run `add()` and `request()`, which stages data to be added and requested. |
| 29 | + |
| 30 | + |
| 31 | + |
| 32 | +## Run Instructions |
| 33 | + |
| 34 | +You can build the project with `gradle build`. |
| 35 | +You can run the client and server using the `run` script with `./run [options]`. The options are: |
| 36 | + |
| 37 | +`--server` : This is if you want to launch the server |
| 38 | + |
| 39 | +`--client` : This is if you want to launch the client |
| 40 | + |
| 41 | +`--host <h>` : This is for the client only, determines what host to connect to |
| 42 | + |
| 43 | +`--port <p>` : If launching as client, tells it to connect to port `p`, and if launching as server, tells what port to server on |
| 44 | + |
| 45 | +`--file <f>` : The path to the script file. Make sure to give the server and client the correct file formats |
| 46 | + |
| 47 | +`--debug` : This is if you want to look at the individual frames being sent and received by the client |
| 48 | + |
| 49 | +`--tests` : This allows you, when you're running the client, to specify the tests you want to run by name. Each test |
| 50 | +should be comma separated. |
| 51 | + |
| 52 | +Examples: |
| 53 | +`./run.sh --server --port 4567 --file src/test/resources/servertest.txt` should start up a server on port `4567` that |
| 54 | +has its behavior determined by the file `servertest.txt`. |
| 55 | + |
| 56 | +`./run.sh --client --host localhost --port 4567 --file src/test/resources/clienttest.txt --debug --tests genericTest,badTest` should |
| 57 | +start the client and have it connect to localhost on port `4567` and load the tests in `clienttest.txt` in debug mode, |
| 58 | +and only run the tests named `genericTest` and `badTest`. |
| 59 | + |
0 commit comments