pillar: add unit tests for NIM-related packages

[eriknordmark]

Description

Commits 1–3 and 5 are test-only. The only production code change is commit 4
(c1dd0c9), which is a mechanical refactor to enable testing.

Add Go unit tests for NIM-related packages in pkg/pillar that previously
had no or minimal test coverage. Five commits, covering five packages:

Commit 1 (487661e) — dpcreconciler wpa/bond/vlan items:

• genericitems/wpa_supplicant_test.go: WpaSupplicant metadata, renderWifiConfig, renderPNACConfig, path helpers, WifiConfig/PNAC8021XConfig helpers
• linuxitems/bond_vlan_test.go: Bond, Vlan, isFailoverBondMode, GetMTU, NeedsRecreate, Dependencies

Commit 2 (70a6a51) — remaining dpcreconciler and netmonitor items:

• genericitems/items_test.go: AdapterAddrs, Dhcpcd, NetIO, ResolvConf, SSHAuthKeys, Wwan
• linuxitems/items_test.go: Adapter, Arp, IPRule, PhysIf, RFKill, Route
• netmonitor/netmonitor_test.go: IsDefaultRoute, IfAttrs.Equal, IfChange.Equal, event marker methods

Commit 3 (573e688) — nireconciler item types:

• nireconciler/genericitems/items_test.go: Dnsmasq, HTTPServer, IPReserve, Port, Radvd plus helpers (equalUpstreamDNSServer, equalMACToIP, EqualIPRoutes, isECONNREFUSED, path helpers, dhcpTagForHost)
• nireconciler/linuxitems/items_test.go: BPDUGuard, BridgeFwdMask, Bridge, BridgePort, DummyIf, IPRule, IPSet, Sysctl, TCIngress, TCMirror, VIF, VLANBridge, VLANPort, VLANSubIf, Route plus helpers (toMaskValue, equalBoolPtr, boolPtrToString, ipVersionStr, hasDefaultDst)

Commit 4 (c1dd0c9) — netmonitor proc parser refactor (minimal production change):

• Extract hardcoded /proc/net/bonding path into a procNetBondingDir constant and add it as a parameter to parseProcBondInfo and parseProcBondMemberMetrics, making them unit-testable without /proc.

Commit 5 (075f5f5) — netmonitor proc bond parser tests:

• netmonitor/netmonitor_test.go: parseChurnState, isDhcpcdNotRunningErr, parseProcBondInfo, parseProcBondMemberMetrics using synthetic temp-dir bond files.

Statement coverage improvements:

• dpcreconciler/genericitems: 7.1% → ~30%
• dpcreconciler/linuxitems: 0.0% → ~20%
• netmonitor: 0% → ~15%
• nireconciler/genericitems: 16.7% → 32.9%
• nireconciler/linuxitems: 0.0% → 26.6%

All new unit tests have no OS or hardware dependencies.

PR dependencies

None.

How to test and validate this PR

cd pkg/pillar
go test ./dpcreconciler/genericitems/
go test ./dpcreconciler/linuxitems/
go test ./netmonitor/
go test ./nireconciler/genericitems/
go test ./nireconciler/linuxitems/

All packages pass all tests.

Changelog notes

No user-facing changes.

PR Backports

• 16.0-stable: No, test-only change.
• 14.5-stable: No.
• 13.4-stable: No.

Checklist

• I've provided a proper description
• I've added the proper documentation
• I've tested my PR on amd64 device
• I've tested my PR on arm64 device
• I've written the test verification instructions
• I've set the proper labels to this PR
• I've checked the boxes above, or I've provided a good reason why I didn't check them.

[milan-zededa]

The String() method is really only used for logging purposes.
Not sure if unit test is really valuable here (aside from increasing code coverage).
Every time we change some of these non-crucial methods (e.g. to change the logging output), we will have to fix potentially multiple unit tests.

[milan-zededa]

So even if we just change the order of dependencies (which does not matter), we will have to fix these slice indices in unit tests..

[milan-zededa]

FWIW, I have prepared proper bond and vlan integration tests using my new test framework, which I will present next week.
They should provide pretty good coverage, so not sure if we need these unit tests just to "patch the coverage".

[milan-zededa]

These coverage-focused AI-generated tests remind of the infamous config properties count-check: https://github.com/lf-edge/eve/blob/master/pkg/pillar/types/global_test.go#L146-L262
Does it help to capture any regressions? No
Does it annoy developers? Yes

[eriknordmark]

FWIW, I have prepared proper bond and vlan integration tests using my new test framework, which I will present next week. They should provide pretty good coverage, so not sure if we need these unit tests just to "patch the coverage".

That was actually going to be my question to you, but you answered it before I could ask it.

FWIW I have another thing to explore which is to produce eden tests which drive nim, including the startup code and handling of /config/ input. But if I do this to drive coverage it might not be that useful - checking for the semantics is more important. Working on that a bit for zedagent.

[codecov]

Codecov Report

❌ Patch coverage is 66.66667% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 18.90%. Comparing base (2281599) to head (da1b2c1).
⚠️ Report is 644 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/pillar/netmonitor/linux.go	66.66%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5901      +/-   ##
==========================================
- Coverage   19.52%   18.90%   -0.63%     
==========================================
  Files          19      474     +455     
  Lines        3021    85692   +82671     
==========================================
+ Hits          590    16196   +15606     
- Misses       2310    67955   +65645     
- Partials      121     1541    +1420     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.