Integration tests for eso::uatools::Client. More...
#include <atomic>#include <chrono>#include <cstdint>#include <cstdlib>#include <filesystem>#include <fstream>#include <mutex>#include <set>#include <string>#include <thread>#include <vector>#include <arpa/inet.h>#include <fcntl.h>#include <netinet/in.h>#include <signal.h>#include <sys/socket.h>#include <sys/wait.h>#include <unistd.h>#include <gtest/gtest.h>#include <eso/uatools/ualib/client.hpp>#include <ifw/fnd/defs/iCommAdapter.hpp>#include <ifw/fnd/defs/logger.hpp>Classes | |
| class | eso::uatools::itest_tests::ItestLoggerEnvironment |
| class | eso::uatools::itest_tests::IntegrationTest |
Namespaces | |
| namespace | eso |
| namespace | eso::uatools |
| namespace | eso::uatools::itest_tests |
Integration tests for eso::uatools::Client.
These tests spawn a real OPC UA server (the UaItestServer CLI binary, with its stdout/stderr redirected to /dev/null) as a child process, then exercise ualib's Client against it. Complements the unit-test suite in ualib/test/ which covers contract-shape only (no network).
Why subprocess and not in-thread? open62541's UA_ServerConfig_setMinimal emits ~12 chatty lines during startup (info/eventloop, warn/server AccessControl, info/session AddNode) BEFORE we can install a custom UA_Logger on the server config. In-process embedding of the server thus leaks those lines into gtest's own stdout. Subprocess execution redirects the child's stdout/stderr to /dev/null so the parent sees nothing — at the cost of ~100 ms fork/exec/wait-for-port overhead per test (acceptable given total runtime <20 s).
Coverage focus: things Robot tests cannot easily express.
Each test uses an ephemeral port so parallel runs don't collide. UATOOLS_ITEST_LOG_LEVEL (env) is forwarded to the child's -l flag so debugging can crank the SDK output up without rebuilding.