A parent ticket for the tickets created to implement a test plan for the [https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle|IEP-90 Client Lifecycle].

Test Plan

Unit Testing

• Make sure that address parsing from string is covered, if supported;
• A logic related to choosing an address for the initial connection should be isolated and covered by the unit tests;
• A logic related to choosing the next connectable address (if possible). Make sure round-robin is used from the random position chosen on the previous step;
• Make sure that the correct port is used by default, if not specified.

Integration Testing

A logic related to address resolving should be covered if possible:

• A single address is provided, that resolves to a single connection point. Make sure the address itself is chosen for the initial connection;
• A single address is provided, that resolves to multiple connection points. Make sure a random address is chosen for the initial connection;
• Multiple addresses are provided, which resolve to multiple connection points. Make sure a random address is chosen for the initial connection.

Functional and End-to-End Testing

• One client, no servers. Make sure client fails to start if no addresses were provided by the user;
• One client, no servers. Make sure client fails to start if no addresses that were provided by the user resolve to the running server;
• One client, one server. Make sure client is able to establish connection to the server if its address specified correctly;
• One client, one server. Make sure client is able to establish connection to the server if its address specified correctly, but there are also some addresses not leading to a running servers;
• One client, two servers, two different clusters. Make sure client is able to establish connection to the first server, but disconnects from the second server after handshake, and does not attempt to connect to it again;
• One mock client, one server. Make sure server rejects connection, if the client does not provide a correct magic bytes at the begging of the handshake;
• One mock client, one server. Make sure server rejects connection, if the client uses unknown protocol version;
• One client, one mock server. Make sure client aborts the connection and provides user with a proper error message, if the server uses unknown protocol version;
• One client, three servers. Make sure client connects to all three of servers, when their addresses are provided by a user;

Security Testing

• It probably makes sense to check our protocol with some kind of vulnerability scanner.

Failover Testing

• One client, two servers. Kill one server, then bring it back up. Make sure client restores the connection to the server;
• One client, two servers. Kill both servers, one-by-one. Make sure client reports error to the user when any operation is attempted;

Load/Stress/Volume Testing

• Test how many connections can a single server handle at the same time.