# GisConverter.TestsApp.ConsoleApp

Integration tests that exercise the ConsoleApp entry point (`Program.Run`) end-to-end using reflection.

---

## Purpose

- Verify CLI parsing, argument repair, logging and host wiring that dispatches conversions to library converters.
- Invoke `Program.Run` directly (do not call `Environment.Exit`) so tests can assert exit codes and console output without spawning a separate process.

---

## Key tests

- Help / no-args behavior
- Unknown conversion option handling
- Repair of unquoted input path tokens (developer convenience)
- Logging initialization and edge cases
- End-to-end conversion scenarios using sample artifacts for Shapefile, CSV and GML
- Output validation (file format, non-empty outputs, data integrity)

---

## How tests locate `Program.Run`

Tests use a robust search strategy to find the ConsoleApp entry point in test runs:
1. `Type.GetType` lookup
2. `Assembly.Load` by assembly name
3. Probe `AppContext.BaseDirectory` for `GisConverter.ConsoleApp*.dll` / `.exe`
4. Walk upward from the base directory to common `bin` output locations

If the `Program` type is not found the test helper throws an informative error showing probed locations — inspect those paths to ensure the ConsoleApp project was built.

---

## Test data

- End-to-end tests expect small sample files under `TestData\<format>` (for example `TestData\Shapefile`).
- Ensure samples are copied to test output by setting `<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>` in the test project.
- Integration tests skip gracefully when required samples are absent so CI remains non-fatal for private or private-only data.

---

## Captured output

- Tests capture `Console.Out` and `Console.Error` to in-memory buffers to assert on user-facing messages.
- For failing conversions (non-zero exit code) tests include combined stdout/stderr in assertions to aid diagnosis.

---

## Detection vs filesystem validation

- Behavior change: the ConsoleApp attempts to auto-detect an appropriate converter for the provided input token before performing a filesystem existence check on the input path. This preserves tolerant repair flows (for example joining adjacent tokens for unquoted paths) and allows tests to exercise parsing/detection logic using synthetic inputs.

- Testing guidance:
  - Some tests intentionally use synthetic input paths (not present on disk) to validate parsing, repair and detection behavior. Because detection runs before the existence check, those tests may observe detection-related messages (for example `Unable to auto-detect converter from input` or a detector reason) instead of an immediate `input path not found` message.
  - Keep assertions tolerant for negative/parse-error flows: accept either detection/usage output OR an input-not-found diagnostic.
  - Example assertion pattern:
    ```csharp
    var combined = stdout + "\n" + stderr;
    Assert.True(
        combined.Contains("Unable to auto-detect converter from input", StringComparison.OrdinalIgnoreCase)
        || combined.Contains("Detector reason", StringComparison.OrdinalIgnoreCase)
        || combined.Contains("Usage", StringComparison.OrdinalIgnoreCase)
        || combined.Contains("input path not found", StringComparison.OrdinalIgnoreCase),
        $"Unexpected CLI output:\n{combined}");
    ```
  - If a test specifically verifies path-existence rejection, create the required filesystem state (create the file or directory) prior to invoking `Program.Run`.

- CLI guidance for consumers:
  - The detect-then-validate order improves developer ergonomics and provides more actionable messages when users mistype or omit options.
  - If your callers or tests rely on immediate filesystem validation semantics, adjust them to supply valid paths or to accept either diagnostic flow.

---

## Running tests

- In IDE: run tests from Test Explorer (ensure the ConsoleApp project is built).
- CLI: `dotnet test ./GisConverter.TestsApp/GisConverter.TestsApp.csproj`.
- For stability on slow CI machines increase retry/wait time helpers used by tests (e.g., file-read retries for log checks).

---

## Debugging

- Use the `GISCONVERTER_DEBUG_TARGET` environment variable in Debug builds to select a predefined scenario (examples: `Shapefile1`, `Csv1`, `Gml1`) and avoid typing long CLI arguments.
- In Visual Studio set __Properties__ → __Debug__ and add `GISCONVERTER_DEBUG_TARGET` to environment variables; debug defaults apply only in Debug builds.
- To reproduce a failing test locally run the ConsoleApp with the same CLI arguments printed by the failing test and capture stdout/stderr.

---

## Notes & best practices

- Tests are best-effort and non-destructive: they create isolated temp folders and clean them up where possible.
- Prefer substring, case-insensitive assertions for messages to make tests resilient to minor wording changes.
- Use the `Logging` test collection for tests that manipulate global logging to avoid parallel execution races.
- Keep sample artifacts small (KB–MB) to keep integration tests fast.

---

## Troubleshooting

- Missing `Program` type in CLI tests: ensure the ConsoleApp project is built and its assembly is present in the probed output directories.
- Log file access or encoding issues: tests use helpers that open files with FileShare.ReadWrite and retry to tolerate logger-held locks.
- Tests expecting licensed functionality: gate them behind environment variables and ensure `AsposeLicenseManager.ApplyLicense()` succeeds or skip.

---

## Contact

Open issues for test failures, missing sample data or flaky behavior. When filing issues include:
- Failing test name and stack trace
- Captured stdout/stderr
- `TestLogger` output (when applicable)
- Path to temporary test root used by the failing test

---