Add unit tests for ADB device-output parsing

[SamratB8]

Summary

Create automated unit tests for the parser that converts adb devices output into structured device models.

The tests should verify normal output, empty output, device-state variations, daemon messages, and malformed lines.

The test suite must not require a physical Android device, emulator, or installed ADB executable.

Background

ADB output may vary based on:

• ADB version
• Device connection state
• USB authorization state
• Operating-system permissions
• Whether the ADB daemon has just started
• Whether adb devices or adb devices -l was used

The parser should remain stable when receiving valid, incomplete, or unexpected output.

Dependencies

This issue depends on:

• Issue Parse adb devices output into device models #6 — Parse adb devices output into device models

If a suitable test project does not exist, this issue may create one.

Proposed Test Project

Possible structure:

tests/
└── WinDroid.Adb.Tests/
    ├── Parsing/
    │   └── AdbDeviceParserTests.cs
    └── WinDroid.Adb.Tests.csproj

Use the test framework already selected by the project.

If no test framework has been selected, choose a common .NET testing framework and avoid adding unnecessary dependencies.

Required Test Cases

One connected device

Example:
``text
List of devices attached
R9CT1234567 device

Expected result:

- One device
- Correct serial number
- State is device

### Multiple connected devices

Example:
```text
List of devices attached
emulator-5554	device
R9CT1234567	device

Expected result:

• Two devices
• Both serial numbers parsed correctly
• Input order preserved unless the parser intentionally documents otherwise

No connected devices

Example:

List of devices attached

Expected result:

• Empty device collection
• No exception

Offline device

Example:

List of devices attached
emulator-5554	offline

Expected result:

• Device is returned
• State is represented as offline

Unauthorized device

Example:

List of devices attached
R9CT1234567	unauthorized

Expected result:

• Device is returned
• State is represented as unauthorized

Permission failure state

Example:

List of devices attached
0123456789ABCDEF	no permissions

Expected result:

• Parser does not crash
• State or raw status remains available

Daemon startup messages

Example:

* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
emulator-5554	device

Expected result:

• Daemon messages are ignored or handled safely
• Device is still parsed

Extended device information

Example:

List of devices attached
emulator-5554 device product:sdk_gphone64_x86_64 model:sdk_gphone64_x86_64 device:emu64xa transport_id:1

Expected result:

• Basic serial and state values are parsed
• Extra attributes do not cause a failure
• Detailed fields may be asserted if already supported

Unknown lines

Example:

List of devices attached
unexpected output that does not match the expected format
emulator-5554	device

Expected result:

• Parser does not throw
• Valid lines are still processed
• Unknown lines are skipped or represented according to documented behavior

Blank and whitespace-only input

Expected result:

• Empty collection
• No exception

Mixed line endings

Test:

Windows \r\n
Unix \n

Expected result:

• Equivalent parsing results

Tasks

• Add or configure an ADB test project
• Reference the ADB project
• Add parser tests
• Add realistic ADB output fixtures
• Cover all required connection states
• Test malformed and unexpected lines
• Test different line endings
• Ensure tests are deterministic
• Ensure tests do not require local ADB
• Add brief comments only where a case is not self-explanatory

Out of Scope

This issue does not need to:

• Execute adb devices
• Detect the local ADB installation
• Connect to a physical Android device
• Test WinUI controls
• Test the process runner
• Add end-to-end device integration tests
• Expand the parser unless a small correction is needed to make valid tests pass

Large parser redesigns should be discussed separately.

Acceptance Criteria

• A dedicated parser test suite exists.
• Tests cover one device, multiple devices, and no devices.
• Tests cover device, offline, and unauthorized states.
• Tests cover daemon startup messages.
• Tests cover malformed or unknown lines.
• Tests cover Windows and Unix line endings.
• Tests do not require an installed ADB executable.
• Tests do not require a connected Android device.
• All tests pass locally.
• The full solution builds successfully in Debug and Release configurations.
• No new compiler warnings are introduced.