DEV Community: Neil Colvin

Write NUnit tests once. Run them on Windows and a Crestron Home processor.

Neil Colvin — Tue, 22 Sep 2026 14:47:31 +0000

Originally published in the Crestron Programmers Group on Groups.io.

By GPT-6 Astra, working through OpenAI’s Codex application. The tools and workflow described here were developed jointly by Neil Colvin and GPT-6 Astra.

A test passing on a Windows development computer is useful evidence. For a Crestron Home developer, it leaves another question: will the same code behave correctly on the processor?

Crestron Home runs on dedicated control processors that connect software drivers to equipment in homes and commercial buildings. Drivers may control heating, lighting and media equipment, or expose information from weather stations and other services. Their underlying libraries often look like ordinary C# libraries, but the processor environment differs from the Windows computer used to develop them.

Filesystem rules, networking, asynchronous operations, assembly loading and runtime behavior can all reveal differences that desktop testing misses.

The central idea behind CrestronHomeNUnit is straightforward: write the NUnit tests once, and run those identical tests on Windows and on the Crestron Home processor.

The fixtures, test cases and assertions remain the same. A processor package supplies the host and packaging needed to execute them on the device. There is no second, manually maintained implementation of the test suite.

That gives developers a fast desktop feedback cycle and a direct check against the environment where their code will actually run.

Three tools support this workflow:

Tool	What it does
Crestron Home NUnit Runner	A Windows application for discovering processor test packages, selecting tests, supplying private inputs and viewing results.
CrestronHomeNUnit.TestAdapter	Integrates a configured development workflow with Visual Studio Test Explorer and VSTest.
CrestronHomeDevTools	A C# library, interactive console and CLI for processor discovery, configuration management and driver lifecycle operations.

They can be used incrementally. A developer can begin with the Windows runner and add automated deployment or CI later.

The tests remain ordinary NUnit tests.

An existing NUnit test project remains the source of its fixtures. Tests might exercise response models, protocol messages, stored settings, error handling or asynchronous connection behavior. The same assertions run locally and remotely.

The processor package targets .NET Framework 4.7.2 and executes under the processor’s Mono runtime. The desktop tooling uses .NET 10. The processor environment also supports the project’s C# 13 compilation setup, with the required compatibility support; newer C# syntax does not make newer runtime APIs appear on the processor.

The stable test host uses NUnit 4.6.1. Tests must use dependencies compatible with their execution targets. A fixture that depends on a Windows-only API cannot become portable simply by placing it inside a processor package. Genuine platform-specific tests should be identified explicitly, while shared tests keep their common implementation.

The processor package guide explains how to generate a package project referencing an existing test project. The shared tooling supplies the host and packaging support.

For a Crestron driver, the processor test project can live in the driver’s solution. A general-purpose library can keep its ordinary NUnit tests in its own repository and put Crestron-specific packaging in a separate collection. That keeps the library useful to consumers who have no involvement with Crestron.

The Windows runner is the simplest starting point.

Each processor test package contains its tests, dependencies, host and its own Crestron Home tile. Packages appear in the Utility category in Configure/Setup. They are self-contained: another NUnit package does not have to be installed first.

After installing a package, the Windows runner discovers it on the network. The developer can connect, choose a suite, run all ordinary tests or select a fixture or individual test, then inspect results and live output.

The package’s standalone Home tile can also run its exposed ordinary suites without the Windows application. Detailed test selection and private live-test inputs are handled through the runner. The tile is not a full substitute for its test-selection interface.

A supplied NUnit self-test and compatibility package provides a useful first check of the environment. Downloading and running the self-contained Windows runner does not require installing Visual Studio or the .NET SDK. Building new processor packages does require the documented development and Crestron packaging tools.

Live tests are an explicit choice.

A parser test needs a payload. A live connection test needs an actual endpoint. A control test may also change a real device.

The same NUnit fixtures can run live tests from Windows or the processor, using private settings appropriate to that environment. Files such as LiveTestSettings.json provide device addresses, selectors and credentials without embedding them in published packages.

Live suites are selected explicitly. An ordinary unit-test run should not unexpectedly switch an outlet, change a room temperature or operate equipment in use.

Tests that change physical state need to capture the starting state, perform the operation, verify its result and restore the state afterward. The tooling supports that workflow, but the fixture author must define what correct behavior and restoration mean for the device.

Separate outcomes matter here: a successful command followed by failed restoration should remain visible as a problem.

Visual Studio can run the complete development cycle.

Ordinary desktop NUnit tests continue to use the normal NUnit adapter. CrestronHomeNUnit.TestAdapter adds a separate .NET 10 workflow project to the solution.

One selectable Test Explorer entry represents a configured workflow. That workflow can:

Run the local tests.
Build the processor test package.
Deploy it and install or update its test instance.
Run the same tests on the processor.
Run explicitly enabled live tests.
Update the actual driver only after the required gates pass, when configured to do so.
Run the configured installed-driver checks and cleanup.

Individual outcomes are reported after execution, with retained results for diagnosis. The workflow entry is the unit of execution: its reported child results are not independent shortcuts around earlier gates.

This is remote test execution, not a remote Visual Studio debugger attachment.

The Test Explorer guide provides the sample project, configuration and validation details. The same workflow backend is available through the CLI, so automation does not depend on Visual Studio being open.

DevTools handles the processor operations around the tests.

Testing on hardware becomes more useful when deployment is repeatable. CrestronHomeDevTools provides processor discovery, inventory, package deployment, installation, updates, configuration inspection and changes, and removal through a modern C# API and console.

The interactive console can discover processors and let the developer select one. Saved Windows profiles protect credentials for the account using them. Automation can use the documented private-input options without putting credentials in source control.

There is an important compatibility distinction: these configuration-management commands require a V2 Crestron Home processor platform. This is separate from the driver generation. A V1 driver on a supported processor may require a reboot during an update; reboot-aware workflows require explicit opt-in.

The management interface is independently implemented and firmware-dependent. Its observed protocol and compatibility limits are documented in the DevTools repository.

CI can use real hardware without requiring a second development laboratory.

One Windows development computer and one compatible processor are enough to start. Additional workers, processors or monitoring computers are optional.

For GitHub Actions, a self-hosted Windows runner with network access to the processor can execute the hardware stages. Hosted CI can still run ordinary desktop tests. The hardware CI guide supplies setup guidance and templates for developers’ own environments.

Shared processor reservations coordinate participating workflows so two jobs do not deploy or update concurrently on the same processor. Those reservations coordinate cooperating tools; they cannot prevent an unrelated manual operation in Configure Pro.

Cleanup is configurable. A successful CI run can remove its test instance and the stored test package it owns, while preserving pre-existing or manually deployed packages. Interrupted or uncertain operations retain evidence for recovery. Some catalogue entries can remain cached until a planned reboot even after package storage has been removed.

For libraries, the workflow can finish after processor tests and cleanup. There need not be an actual Crestron driver to update.

UI testing is an optional additional layer.

For drivers with a user interface, C# NUnit fixtures can use the included UI automation library to inspect the Crestron Home Android app through ADB. An Android emulator running the app provides a way to verify visible state as well as API results.

That requires separate emulator and app setup. It is not needed for ordinary library or processor tests. The Android emulator guide covers that setup, and the UI testing guide explains the fixture APIs and limits.

Developers write C# tests and configure documented workflows. They do not need an AI assistant, Linux administration knowledge or Python programming knowledge to use the normal workflow.

The practical starting point is small: take one existing NUnit suite, run it locally, package it, and run those same tests on the processor. Once that is working, add deployment automation, live tests and CI as the project needs them.

The projects are publicly available:

Feedback from other Crestron developers is welcome, particularly reports of runtime differences, unclear setup steps and reproducible problems. Please leave credentials and private installation details out of public reports.

Original project code is MIT licensed; NUnit and other dependencies retain their own licenses and acknowledgments. Crestron and Crestron Home are trademarks or registered trademarks of Crestron Electronics, Inc. These are independent community tools, not products affiliated with or endorsed by Crestron or NUnit.

System.Text.Json vs Newtonsoft.Json on a Crestron MC4-R (Mono/net472): measured on the processor

Neil Colvin — Tue, 22 Sep 2026 13:26:00 +0000

Most published STJ-vs-Newtonsoft benchmarks run on desktop or server .NET 8–10. I needed numbers for the runtime my Crestron Home drivers actually run on, so I measured on the processor itself.

Setup

Hardware: Crestron MC4-R (hardware version 2), firmware 2.8000.00057 (built 17 Sep 2025), Crestron Home 4.011.0322
Runtime: Mono 6.12.0.107, CLR version 4.0.30319.42000, OS reported as Unix 4.19.35.5149
Serialisers: System.Text.Json 10.0.12 and Newtonsoft.Json 13.0.5-beta1. The Newtonsoft version was the driver's existing dependency. It's a prerelease that has since been unlisted on NuGet, and the latest stable is 13.0.4. I haven't rerun against 13.0.4. Both serialisers were merged into the test package as private copies.
Payload: a synthetic 409-byte response shaped like a WeatherLink API response, deserialised into the same nullable DTOs, which carry attributes for both serialisers. STJ runs with AllowReadingFromString, and Newtonsoft uses its defaults. Results are checked for correctness.
Method: Debug harness build (the serialisers are the precompiled NuGet release binaries). 200 warm-up parses per serialiser, then 4 alternating rounds of 3,000 synchronous deserialisations, with a GC before each round. Time is measured with Stopwatch and allocations with GC.GetAllocatedBytesForCurrentThread.
Harness: NUnit fixtures run remotely on the processor through my own test adapter (CrestronHomeNUnit).

Results (MC4-R, 3,000 parses per round)

Round	System.Text.Json	Newtonsoft 13.0.5-beta1	STJ time saving
0	324.553 ms	440.976 ms	26.40%
1	324.821 ms	442.914 ms	26.66%
2	323.404 ms	440.126 ms	26.52%
3	324.255 ms	441.608 ms	26.57%
Per parse	0.108 ms	0.147 ms	26.5%
Allocated per parse	1,024 B	3,816 B	73.2% fewer

Each serialiser's round times stayed within 0.63% of its mean. A short check on desktop .NET 10 also favoured STJ, but its timings varied too much to quote.

Follow-up: STJ vs the processor's resident Newtonsoft (22 Sep)

A second fixture compared bundled STJ with the Newtonsoft.Json already on the processor. That's standard Newtonsoft 13.0.2 at /simpl/app00/, left out of the merge and checked by identity before timing. As in the first run, both packages were Debug harness builds. They ran one after the other in separate host processes.

Round (3,000 parses)	Bundled STJ 10.0.12	Resident Newtonsoft 13.0.2
0	324.699 ms	431.950 ms
1	388.026 ms	430.408 ms
2	326.794 ms	430.696 ms
3	326.157 ms	431.120 ms
Per parse	0.114 ms	0.144 ms
Allocated per parse	1,024 B	3,816 B

STJ was about 21% faster overall. Leaving out the slow round 1, it was about 24% faster. The allocation difference is identical to the first run. The raw results include process memory snapshots, but the two runs started from different managed heaps (about 67 MB and 20 MB). Those figures measure host-process state, not serialiser cost, so don't compare them.

What this does and doesn't show

On Mono, STJ allocates about a quarter as much as Newtonsoft and parses about 21–27% faster for this payload.
These tests used warmed parsing and one small payload shape. They don't cover cold start, serialisation, peak memory or whole-driver CPU.
At weather-polling intervals the absolute CPU savings are small. The allocation reduction matters more on a processor shared with other drivers.

Deployment note for Crestron developers

On this firmware, both standard Newtonsoft.Json 13.0.2 and Newtonsoft.Json.Compact 4.0.8.0 are resident in /simpl/app00/, and System.Text.Json isn't. Crestron's driver best-practices page lists Newtonsoft.Json among the DLLs Home loads, but still advises merging your dependencies to avoid DLL conflicts. So STJ has to ship inside your package, and so should Newtonsoft if you use it. None of this was measured against the Compact assembly. That's one firmware on one processor, not a platform guarantee.

Reproduce it

Fixtures, payload, raw results and processor harnesses

AI disclosure: the benchmark fixtures and processor runs were done by GPT-6 Astra, and this write-up was generated by Claude, under my direction.