Files
TeslaSuite/Console/tests/TeslaConsole.DiffTests
CydandClaude Opus 4.8 78bf297824 Bump version to 4.11.4.1; show version in Agent tray menu
- Console AssemblyVersion/AssemblyFileVersion 4.11.3.37076 -> 4.11.4.1. The
  recovered console is no longer a byte-faithful copy of the original baseline;
  it is the modernized 4.11.4.x line.
- Launcher Service + Agent Version -> 4.11.4.1 (unified suite version). The Agent
  tray menu header now shows the running version ("Tesla Launcher Agent  v4.11.4.1").
- Differential tests: the identity guard now expects the original at 4.11.3.37076
  and the recovered at 4.11.4.1 (not identical); the public-member surface check
  strips Version= stamps before comparing, since generic-argument signatures embed
  the assembly version (we compare type names, not versions). 73 tests green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-30 10:02:39 -05:00
..

TeslaConsole.DiffTests — differential equivalence suite

Verifies that the reconstructed TeslaConsole.exe (built from the decompiled source in this repo) behaves identically to the original reference binary in original/TeslaConsole.exe.

How it works

Both files carry the exact same assembly identity (TeslaConsole, Version=4.11.3.37076), so the .NET loader will not hold both in one AppDomain. The suite therefore loads each assembly into its own child AppDomain (DifferentialFixture) and drives it through a MarshalByRefObject proxy (Invoker). This is why the project targets net48 — AppDomains are a .NET Framework feature.

Each child domain is given a probe directory (the recovered build's output, which ships every dependency DLL) so the original — which is distributed without its proprietary dependencies — still resolves its references for metadata inspection.

What is compared

  1. Public API surface (PublicApiSurfaceTests) Every public type and public member (signature-for-signature) exposed by the original must also be exposed by the recovered build. Compiler-generated members and property/event accessor methods are excluded — the README at the repo root notes those legitimately differ between a decompilation and the lost sources.

  2. Behavioral output (BehavioralEquivalenceTests) The same deterministic, dependency-free methods are invoked in both assemblies over a battery of inputs and the results must match byte-for-byte:

    • RPStrings.GetTimeString (mm:ss formatting + 0.5 s rounding)
    • HostTypeHelper.Parse(...).ToString() (incl. invalid-input exceptions)
    • PlasmaBitmaps.ConvertBitmap (1-bpp packing of a known pixel pattern)
    • PlasmaBitmaps.GenerateString (full GDI text → 1-bpp plasma pipeline)
    • RPMap / RPVehicle XML parsing
    • SiteManagement well-known application GUID constants
    • Tuple.Create<,> generic factory

    A negative-control test (Harness_Distinguishes_Different_Outputs) proves the harness can actually see a difference, so a green run is never vacuous.

Running

dotnet test tests/TeslaConsole.DiffTests/TeslaConsole.DiffTests.csproj

A project reference builds the reconstruction first, and the suite always tests the most recently built bin/{Debug,Release}/net48/TeslaConsole.exe.

Scope / limitations

This compares deterministic logic. It deliberately does not drive the WinForms UI, the pod networking, secure-configuration, or hardware-facing code — those require the live console, its pods, and the proprietary services, and are not reproducible in a unit test. The API-surface test still asserts those types exist with matching signatures even though their behavior isn't exercised.