using DodoSSH.Client.Shell.ViewModels;
using DodoSSH.Client.Transfer;

namespace DodoSSH.Client.App.Tests;

/// <summary>What the local pane's root chips are called.</summary>
/// <remarks>
/// A chip carries a name and never a path — the path is the chip's command parameter, where its length costs
/// nothing. The derivation used to be <c>TrimEnd(separator)</c>, which is a name only for a Windows drive:
/// on Unix it made the <c>/</c> chip an empty pill and the home chip the whole home path, and a home
/// directory deep enough pushed the pane header's own buttons out of the window — CI's per-job HOME is what
/// finally said so. These pin the derivation with fixed strings, so the question no longer depends on how
/// long a path any particular machine keeps its profile under.
/// </remarks>
public sealed class RootChipNameTests
{
    [Fact]
    public void TheUnixRootIsASlash_NotAnEmptyPill() =>
        TransfersViewModel.RootChipName("/").ShouldBe("/");

    /// <remarks>
    /// The one substitution rather than a shortening: every shell already means "my home directory" by
    /// <c>~</c>, and the machine's real home path — however deep — stays on the chip's command alone.
    /// </remarks>
    [Fact]
    public void TheHomeChipIsATilde_HoweverDeepHomeSits() =>
        TransfersViewModel.RootChipName(LocalDirectory.Home).ShouldBe("~");

    [Fact]
    public void AMountNamesItselfByItsLastSegment() =>
        TransfersViewModel.RootChipName("/media/usb0").ShouldBe("usb0");

    /// <remarks>
    /// Windows only, because the input only exists there — <c>LocalDirectory.Roots()</c> produces drive
    /// roots on no other platform, and <c>Path.GetFileName</c> reads <c>C:\</c> differently on Unix.
    /// </remarks>
    [Fact]
    public void AWindowsDriveKeepsItsTwoCharacterName()
    {
        if (!OperatingSystem.IsWindows())
        {
            return;
        }

        TransfersViewModel.RootChipName(@"C:\").ShouldBe("C:");
    }
}