Igor Sapego created IGNITE-21778:
------------------------------------
Summary: Client lifecycle testing
Key: IGNITE-21778
URL: https://issues.apache.org/jira/browse/IGNITE-21778
Project: Ignite
Issue Type: Epic
Components: platforms, thin client
Reporter: Igor Sapego
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].
h1. Test Plan
h2. 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.
h2. 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.
h2. 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;
h2. Security Testing
- It probably makes sense to check our protocol with some kind of vulnerability
scanner.
h2. 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;
h2. Load/Stress/Volume Testing
- Test how many connections can a single server handle at the same time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
