You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#This target is to ensure accidental execution of Makefile as a bash script will not execute commands like rm in unexpected directories and exit gracefully.
#This target is to ensure accidental execution of Makefile as a bash script will not execute commands like rm in unexpected directories and exit gracefully.
#This target is to ensure accidental execution of Makefile as a bash script will not execute commands like rm in unexpected directories and exit gracefully.
This folder contains tests to verify SDK functionality. These have been tested to work with Linux but haven't been ported to any specific platform. For additional information about porting the Device SDK for embedded C onto additional platforms please refer to the [PortingGuide](https://github.com/aws/aws-iot-device-sdk-embedded-c/blob/master/PortingGuide.md/).
3
+
A description for each folder is given below
4
+
5
+
## integration
6
+
This folder contains integration tests that run directly against the server. For further information on how to run these tests check out the [Integration Test README](https://github.com/aws/aws-iot-device-sdk-embedded-c/blob/master/tests/integration/README.md/).
This folder contains integration tests to verify Embedded C SDK functionality. These have been tested to work with Linux but haven't been ported to any specific platform. For additional information about porting the Device SDK for embedded C onto additional platforms please refer to the [PortingGuide](https://github.com/aws/aws-iot-device-sdk-embedded-c/blob/master/PortingGuide.md/).
3
+
To run these tests, follow the below steps:
4
+
5
+
* Place device identity cert and private key in locations referenced in the `certs` folder
6
+
* Download certificate authority CA file from [Symantec](https://www.symantec.com/content/en/us/enterprise/verisign/roots/VeriSign-Class%203-Public-Primary-Certification-Authority-G5.pem) and place in `certs` folder
7
+
* Ensure the names of the cert files are the same as in the `aws_iot_config.h` file
8
+
* Ensure the certificate has an attached policy which allows the proper permissions for AWS IoT
9
+
* Update the Host endpoint in the `aws_iot_config.h` file
10
+
* Build the example using make. (''make''). The tests will run automatically as a part of the build process
11
+
* For more detailed Debug output, enable the IOT_DEBUG flag in `Logging level control` section of the Makefile. IOT_TRACE can be enabled as well for very detailed information on what functions are being executed
12
+
* More information on the each test is below
13
+
14
+
### Integration test configuration
15
+
For all the tests below, there is additional configuration in the `integ_tests_config.h`. The configuration options are explained below:
16
+
17
+
* PUBLISH_COUNT - Number of messages to publish in each publish thread
18
+
* MAX_PUB_THREAD_COUNT - Maximum number of threads to create for the multi-threading test
19
+
* RX_RECEIVE_PERCENTAGE - Minimum percentage of messages that must be received back by the yield thread. This is here ONLY because sometimes the yield thread doesn't get scheduled before the publish thread when it is created. In every other case, 100% messages should be received
20
+
* CONNECT_MAX_ATTEMPT_COUNT - Max number of initial connect retries
21
+
* THREAD_SLEEP_INTERVAL_USEC - Interval that each thread sleeps for
22
+
* INTEGRATION_TEST_TOPIC - Test topic to publish on
23
+
* INTEGRATION_TEST_CLIENT_ID - Client ID to be used for single client tests
24
+
* INTEGRATION_TEST_CLIENT_ID_PUB, INTEGRATION_TEST_CLIENT_ID_SUB - Client IDs to be used for multiple client tests
25
+
26
+
### Test 1 - Basic Connectivity Test
27
+
This test verifies basic connectivity with the server. It creates one client instance and connects to the server. It subscribes to the Integration Test topic. Then it creates two threads, one publish thread and one yield thread. The publish thread publishes `PUBLISH_COUNT` messages on the test topic and the yield thread receives them. Once all the messages are published, the program waits for 1 sec to ensure all the messages have sufficient time to be received.
28
+
The test ends with the program verifying that all the messages were received and no other errors occurred.
29
+
30
+
### Test 2 - Multiple Client Connectivity Test
31
+
This test verifies usage of multiple clients in the same application. It creates two client instances and both connect to the server. One client instance subscribes to the Integration Test topic. The other client instance publishes `PUBLISH_COUNT` messages on the test topic and the yield instance receives them. Once all the messages are published, the program waits for 1 sec to ensure all the messages have sufficient time to be received.
32
+
The test ends with the program verifying that all the messages were received and no other errors occurred.
33
+
34
+
### Test 3 - Auto Reconnect Test
35
+
This test verifies Auto-reconnect functionality. It creates one client instance. Then it performs 3 separate tests
36
+
37
+
* Tests the disconnect handler by causing a TLS layer disconnect.
38
+
* Tests manual reconnect API by causing a TLS layer disconnect with auto-reconnect disabled
39
+
* Lastly, it tests the Auto-reconnect API by enabling auto-reconnect. It renames the rootCA file to a different name to prevent immediate reconnect, verifies the error codes are returned properly and that the reconnect algorithm is running. Once that check is satisfied, it renames the rootCA file back to the original names and verifies the client was able to reconnect.
40
+
41
+
### Test 4 - Multi-threading Validation Test
42
+
This test is used to validate thread-safe operations. This creates on client instance, one yield thread, one thread to test subscribe/unsubscribe behavior and MAX_PUB_THREAD_COUNT number of publish threads. Then it proceeds to publish PUBLISH_COUNT messages on the test topic from each publish thread. The subscribe/unsubscribe thread runs in the background constantly subscribing and unsubscribing to a second test topic. The yield threads records which messages were received.
43
+
44
+
The test verifies whether all the messages that were published were received or not. It also checks for errors that could occur in multi-threaded scenarios. The test has been run with 10 threads sending 500 messages each and verified to be working fine. It can be used as a reference testing application to validate whether your use case will work with multi-threading enabled.
0 commit comments