dohertj2/lmxopcua
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Task #253 follow-up — bidirectional + subscribe-sees-change e2e stages

Browse Source 
The original three-stage design (probe / driver-loopback / forward-
bridge) only proved driver-write → server-read. It missed:

 - OPC UA write → server → driver → PLC (the reverse direction)
 - server-side data-change notifications actually firing (a stale
   subscription can still let a read-after-the-fact return the new
   value and look fine)

Extend _common.ps1 with two helpers:

 - Test-OpcUaWriteBridge: otopcua-cli write the NodeId -> wait 3s ->
   driver CLI read the PLC side, assert equality.
 - Test-SubscribeSeesChange: Start-Process otopcua-cli subscribe in the
   background with --duration N, settle 2s, driver-side write, wait for
   the subscription window to close, assert captured stdout contains
   the new value.

Wire both into test-modbus / test-abcip / test-ablegacy / test-s7 /
test-focas / test-twincat after the existing forward-bridge stage.
Update README to describe the five-stage design + note that the
published NodeId must be writable for stages 4 + 5.

Also prepend UTF-8 BOM to every script in scripts/e2e so Windows
PowerShell 5.1 parsers agree on em-dash byte sequences the way
PowerShell 7 already does. The scripts still #Requires -Version 7.0 —
the BOM is purely defensive for IDE / CI step parsers.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Joseph Doherty
2026-04-21 10:08:52 -04:00
parent 097f92fdb8
commit a9b585ac5b
10 changed files with 264 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
scripts/e2e/README.md
View File

@@ -12,25 +12,44 @@ tests (`tests/.../IntegrationTests/`) confirm the driver sees the PLC, and
the OPC UA `Client.CLI.Tests` confirm the client sees the server — but
nothing glued them end-to-end. These scripts close that loop.
## Three-stage test per driver
## Five-stage test per driver
Every per-driver script runs the same three tests:
Every per-driver script runs the same five tests. The goal is to prove
**both directions** across the bridge plus subscription delivery —
forward-only coverage would miss writable-flag drops, `IWritable`
dispatch bugs, and broken data-change notification paths where a fresh
read still returns the right value.
1. **`probe`** — driver CLI opens a session + reads a sentinel. Confirms
the simulator / PLC is reachable and speaking the protocol.
2. **Driver loopback** — write a random value via the driver CLI, read it
back via the same CLI. Confirms the driver round-trips without
2. **Driver loopback** — write a random value via the driver CLI, read
it back via the same CLI. Confirms the driver round-trips without
involving the OPC UA server. A failure here is a driver bug, not a
server-bridge bug.
3. **Server bridge** — write a different random value via the driver
CLI, wait `--ServerPollDelaySec` (default 3s), read the OPC UA NodeId
the server publishes that tag at via `otopcua-cli read`. Confirms the
full path: driver CLI → PLC → OtOpcUa server → OPC UA client.
3. **Forward bridge (driver → server → client)** — write a different
random value via the driver CLI, wait `--ServerPollDelaySec` (default
3s), read the OPC UA NodeId the server publishes that tag at via
`otopcua-cli read`. Confirms reads propagate from PLC to OPC UA
client.
4. **Reverse bridge (client → server → driver)** — write a fresh random
value via `otopcua-cli write` against the same NodeId, wait
`--DriverPollDelaySec` (default 3s), read the PLC-side via the
driver CLI. Confirms writes propagate the other way — catches
writable-flag drops, ACL misconfiguration, and `IWritable` dispatch
bugs the forward test can't see.
5. **Subscribe-sees-change** — start `otopcua-cli subscribe --duration N`
in the background, give it `--SettleSec` (default 2s) to attach,
write a random value via the driver CLI, wait for the subscription
window to close, and assert the captured output mentions the new
value. Confirms the server's monitored-item + data-change path
actually fires — not just that a fresh read returns the new value.
The OtOpcUa server must already be running with a config that
(a) binds a driver instance to the same PLC the script points at, and
(b) publishes the address the script writes under a NodeId the script
knows. Those NodeIds live in `e2e-config.json` (see below).
knows. Those NodeIds live in `e2e-config.json` (see below). The
published tag must be **writable** — stages 4 + 5 will fail against a
read-only tag.
## Prereqs