Files

T

CydandClaude Opus 4.8 d5c4be26ce Docs: bring READMEs in line with current state (net48, JSON wire)

- Root README: launcher is .NET Framework 4.8 (was .NET 6/x86); RPC is framed
  JSON (was BinaryFormatter); added Contract/ + SecureConfig/; dropped the
  now-resolved "known duplication" warning; corrected the lib/*.dll note
  (TeslaConsoleLaunchLib/TeslaSecureConfiguration are source-built, kept only as
  test baselines); added a short history section.
- Console README: Contract is net48-only; Launcher targets net48.
- Launcher README: net48 framework-dependent (was net8/x64 self-contained);
  needs .NET Framework 4.8 (built into Windows), no bundled runtime.
- DiffTests README: original 4.11.3.37076 vs recovered 4.11.4.x (no longer share
  identity); noted version-insensitive comparison + the new protocol/crypto guards.
- Removed Launcher/assets/MEMORY.md (stale leftover dev-notes, superseded by the
  README and now-moot post-BinaryFormatter).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-30 13:44:06 -05:00

3.5 KiB

Raw Blame History

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

The suite 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. The original is the 4.11.3.37076 baseline; the recovered build is the modernized 4.11.4.x line (same TeslaConsole assembly name, an intentionally newer version). Because the two versions differ, the public-member comparison strips Version= stamps before diffing — it compares type/member names, not assembly versions.

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

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.
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.

The project also carries two byte-compatibility guards — not original-vs-recovered comparisons, but checks that the modernized protocol/crypto stays compatible with the original binaries:

PodRpcProtocolTests — round-trips the framed-JSON RPC (Contract/PodRpcProtocol.cs) in-process: every request/response shape encodes and decodes back to the same values.
SecureConfigCompatTests — asserts the source-built OFBCryptoStream produces byte-identical ciphertext to the original TeslaSecureConfiguration.dll, so the pod provisioning handshake stays wire-compatible.

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.

3.5 KiB Raw Blame History