This will output `selftest` and `echotest` to `build/$PLATFORM/`
*Note, the following examples assume your testing environment is `linux`, you'll see this in the build output path. If this is not true, change it to `darwin`, `freebsd`, or `win` depending on what you're running.*
### Step 3. Define your test configuration in `test/selftest.conf`:
This is essentially just a listing of libzt-based app identities and host machine identities. We will be conducting `library-to-remote-library`, `library-to-remote-host`, and `remote-host-to-library` tests over the network. For this reason we need to define who should be talking to who.
A simple test configutation might look like the following. This will create an `alice` and `bob` test personality, that is, we will run one instance of the library as a server (alice), and one instance of the `echotest` on the same host machine. `echotest` is merely a program to record timings for transmitted data and also generate data for the library to receive). Additionally we will be running a library as a client `bob` on another remote host as well as another instance of `echotest` on that same machine. In this configuration the following will happen:
-`alice` libzt will tx/rx to/from `bob` libzt
-`alice` libzt will send X bytes to `bob`'s `echotest` to test maximum TX rate
-`alice` libzt will request X bytes from `bob`'s `echotest` to test maximum RX rate
-`bob` libzt will send X bytes to `alice`'s `echotest` to test maximum TX rate
-`bob` libzt will request X bytes from `alice`'s `echotest` to test maximum RX rate
```
# Tests will use ports starting from 'port' to 'port+n' where 'n' is the number of tests
The self test will be performed over the network in the following configuration (addresses and ports are subject to change depending on what you define in your `test/*.conf` files):
- Slam tests will test the library's ability to handle many repeated API calls or repeated common sequences of API calls that a typical application may make. For instance, it will try to create as many sockets as possible, or try to create a socket, bind to an address, listen, and accept over and over. This is useful for detecting memory leaks and architectural limitations in the stack drivers.