Added four comprehensive test scenarios using `unittest.mock.patch` to
verify `_resolvers_unix` in `src/netsleuth/netinfo.py`. These cover parsing
`/etc/resolv.conf`, parsing `scutil --dns` output on macOS, correctly combining
the results of both, and gracefully handling missing files and failing
subprocess commands.
This increases `netinfo.py` test coverage and ensures robust parsing logic for
system DNS resolvers.
Co-authored-by: Horizontal42 <75383519+Horizontal42@users.noreply.github.com>
* 🧪 Add tests for primary_interface_ip
Added unit tests to fully cover `primary_interface_ip` in `netinfo.py`, handling IPv4, IPv6 and error conditions using mock sockets.
Coverage for `primary_interface_ip` is now 100%.
Co-authored-by: Horizontal42 <75383519+Horizontal42@users.noreply.github.com>
* drop redundant pytest-cov dep addition
---------
Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
This addresses the missing coverage for local network parameter discovery. Tests cover happy paths, CGNAT scenarios, and cases with no network components. The additions improve reliability and prevent regression of core host capability detection.
Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
Added tests for the `detect_capabilities` function in `src/netsleuth/netinfo.py` to cover both Linux and Windows OS flows, improving test coverage and reliability.
Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
This commit adds a new test file, `tests/test_cli.py`, containing
unit tests for the `_os_timezone` function in `netsleuth.cli`.
The tests cover:
- Happy paths (TZ variable, /etc/localtime symlink, /etc/timezone file)
- The edge case of an `OSError` exception being thrown when reading the
/etc/timezone file.
Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
_default_gateway() took whichever 0.0.0.0 line route print printed first,
not the one Windows actually uses (lowest metric). With a VPN adapter
installed (Radmin VPN, Tailscale, ...) its default-ish route can print
before the real one. Verified live: was reporting Radmin VPN's 26.0.0.1
while Ethernet (the interface actually carrying traffic, confirmed via
primary_interface_ip()) has gateway 192.168.3.1; now reports that correctly.
Parsing extracted into pure _parse_windows_default_gateway(), tested against
a captured multi-adapter route print sample.
