Skip to content

Testing

The control code has two test layers: an automated pytest smoke suite that runs without hardware, and a manual hardware bring-up routine that runs against the real drive and DAQ.

Automated: code/adcl_winsoft/tests/

Five non-Qt smoke tests in tests/test_smoke.py. They exercise the parts of the code that do not need a display server, a Modbus slave, or NI-DAQmx.

Run

From a Windows venv or a Linux/macOS one (as long as you have not asked it to import Qt):

cd code/adcl_winsoft
pytest -q

All five tests should pass.

What they cover

Test What it checks
Modbus address calculation group × 100 + index − 1 produces the expected register addresses for known parameters.
Calibration round-trip REF1 = drive_RPM × 22.42 and the inverse agree to within float precision.
Settings persistence A round-trip through config/settings.py of a non-trivial settings dict reproduces the original.
Admin hash verify Setting and verifying an Argon2id hash works for known good and known bad inputs.
Calibration matrix application Applying a known PGB matrix to a known input vector produces the expected output.

When to add a test

Any time you add a calibration constant, a settings key, a Modbus address, or a hash routine. The test should be cheap (sub-second), hardware-free, and assert one specific behaviour. If a bug ever reaches the lab, the easiest mitigation is to land a regression test alongside the fix.

What is not covered

  • The Qt UI. We do not run Qt under pytest in this project — too much setup, too little signal.
  • The actual NI-DAQmx integration. The reader's simulated fallback is what the tests exercise.
  • The actual Modbus integration. The tests use mocks where they touch pymodbus.

Manual: hardware bring-up

The hardware-side validation that the automated tests cannot do. Run this:

  • after a software change that touches the VFD or DAQ path;
  • after any drive-parameter change;
  • after a long facility idle period;
  • before a first run of the day if any of the above applies.

Procedure

  1. Pre-run checklist complete (Operations → Pre-run checklist).
  2. Modbus reachability: Test-NetConnection -ComputerName 192.168.50.10 -Port 502 → TcpTestSucceeded : True.
  3. PowerShell control sanity:
    • Launch WindTunnelControl.ps1.
    • Confirm the live readout is updating (CW, REF1, SW, ACT1).
    • Apply a low setpoint (e.g. 100 RPM), Start, observe motor spin to 100 RPM.
    • Apply 200 RPM mid-run, observe smooth transition.
    • Stop, verify motor reaches 0 RPM.
    • E-Stop test: re-start at 100 RPM, press E-Stop, verify coast-down.
  4. ADCL WinSoft control sanity:
    • Launch ADCL WinSoft.exe.
    • Confirm footer shows Connected (Modbus) and DAQ: cDAQ1 (or simulated if the DAQ is intentionally bypassed).
    • Repeat the 100 → 200 → 0 → 100 → E-Stop sequence in the UI.
  5. DAQ sanity:
    • With the tunnel stopped, press Start DAQ in ADCL WinSoft.
    • Confirm Signals tab shows reasonable engineering-unit readings — pressures near zero, angle near sensor zero, PGB sting forces near zero.
    • Spin the tunnel to 400 RPM, confirm the static-ring pressure increases and velocity_mps reports a sensible value.
    • Stop, press Stop DAQ, confirm the CSV closes.
  6. CSV format spot check:
    • Open the just-written CSV in a text editor.
    • Confirm the header line matches the expected column set from Operations → Data acquisition workflow.
    • Confirm timestamps increase monotonically and at the expected rate.

Logging

Anything unexpected — fault codes, missing channels, calibration drift — gets a new WT_MS_<n>/debug_session.md. This is the only way the team builds up a track record of what is normal for this facility.