In dieser Episode spricht Richard Seidl mit Johannes Stiller von Stiftung Warentest über die Testmethoden und Entscheidungsprozesse bei Produktprüfungen. Es geht darum, wie die Stiftung ihre Prüfprogramme entwickelt, welche Kriterien für verschiedene Produkte gelten und wie Teams aus Wissenschaftlern und Marktanalysten zusammenarbeiten. Besonders spannend: die Parallelen zum Softwaretesting, etwa Objektivität, Transparenz und die Perspektive des Nutzers. Wie funktioniert die Auswahl der getesteten Produkte und wie werden subjektive Eindrücke bei Zahnbürsten oder Laptops möglichst vergleichbar gemacht?

Johannes Stiller schloss 2016 seine Promotion im Bereich der nuklearen Kern- und Teilchenphysik in Heidelberg ab. Während dieser Zeit arbeitete er intensiv vor Ort am CERN am ALICE-Experiment. Aufgrund seiner Expertise in Tracking-Algorithmen wechselte er anschließend in die Softwareentwicklung der Automobilindustrie. Ein wesentlicher Meilenstein war seine maßgebliche Beteiligung an den Sicherheitsbremssystemen für das autonome Parkshuttle-System Parkshuttle Rivium. Nach seinem Umzug nach Berlin widmete er sich im VW-Konzern der Serienentwicklung von Fahrassistenzsystemen wie dem Emergency Assist und dem Travel Assist, inklusive der ASPICE-konformen Entwicklung, Prüfung und Freigabe. Seit August 2025 bekleidet Johannes Stiller eine leitende Funktion bei der Stiftung Warentest, wobei ihn besonders die Möglichkeit motiviert, vielseitige Themen auf wissenschaftlich fundierter Basis zu bearbeiten.

Software-Testing im Gespräch

Bei diesem Format dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „So testet Stiftung Warentest – Johannes Stiller“.

(mai)

Das direkte Übersetzen und Starten von C#-Dateien nennt Microsoft File-based Apps. Für Informationen, die üblicherweise in der .csproj-Projektdatei liegen, hat Microsoft für File-based Apps eine eigene Syntax eingeführt.

Die Syntax beginnt mit der Raute # (eine Präprozessor-Direktive in C#) gefolgt von einem Doppelpunkt (aus der Sicht des C#-Compilers eine zu ignorierende Direktive):

• Festlegung des SDKs: #:sdk Microsoft.NET.Sdk.Web. Bei der Angabe des SDK kann man ab Preview 6 auch die Versionsnummer nach @ angeben, beispielsweise #:sdk Aspire.AppHost.Sdk@9.3.1
• Referenz auf ein NuGet-Paket: #:package Console@0.48.*
• Referenz auf Projekte: #:project ./ClassLib/ClassLib.csproj
• Build-Eigenschaften, z. B. Versionsnummer: #:property Version=1.1.2 (vor Preview 6 noch ohne Gleichheitszeichen, sondern mit Leerzeichen als Trennung)
• File-based Apps verwenden im Standard den NativeAOT-Compiler. Wenn man ihn mit #:property PublishAot=false deaktiviert, wird der Just-in-Time-Compiler verwendet.

Weitere Features von Files-based Apps sind:

• Man kann eine Datei .settings.json im gleichen Ordner mit den Settings für die File-based App anlegen.
• Man kann in der Datei .run.json im gleichen Ordner ein Launch-Profil für die File-based App anlegen.
• Man kann dotnet build Dateiname.cs oder dotnet restore Dateiname.cs ausführen.
• Man kann solche File-based Apps mit dotnet publish cs zu einer ausführbaren Datei (.EXE) übersetzen.
• Innerhalb einer File-based App können Entwicklerinnen und Entwickler seit Preview 6 den Standort der Datei mit AppContext.GetData("EntryPointFileDirectoryPath") und den ganzen Pfad zur ausgeführten C#-Datei mit GetData("EntryPointFilePath") bestimmen. Das funktioniert allerdings nur mit File-based Apps, nicht in normalen, projektbasierten C#-Anwendungen.

Es gibt aber in .NET 10.0 noch keine Möglichkeit, in einer File-based App eine andere .cs-Datei direkt einzubinden. Das ist für .NET 11.0 geplant.

Folgender Code zeigt ein Beispiel einer File-based App mit zwei referenzierten NuGet-Paketen:

#!/usr/bin/env dotnet
#region Einstellungen für File-based App
// 
#:package Humanizer@2.14.1 
// 
#:package Spectre.Console@0.*
#:property LangVersion=preview
#:property Version=1.2.0
#:project ./ClassLibrary/ClassLibrary.csproj
#endregion
using Spectre.Console;
using Humanizer;

var title = "C# Script v" + System.Reflection.Assembly.GetExecutingAssembly().GetName().Version +
" mit " + System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription + "\n" +
AppContext.GetData("EntryPointFilePath");

// Header
AnsiConsole.Write(
    new Panel(title)
        .Header("[yellow]File-based App[/]", Justify.Center)
        .Border(BoxBorder.Rounded)
        .BorderStyle(new Style(foreground: Color.Green))
        .Padding(1, 1, 1, 1)
);

// Parameter auflisten
foreach (var arg in args)
{
    Console.WriteLine($"Argument: {arg}");
}

Console.WriteLine();

// Daten
(Data net80, Data net90, Data net10) = GetData();

// Textausgabe in Wochen
var dotNet8Released = DateTimeOffset.Parse(net80.Release);
TimeSpan dotNet8Since = DateTimeOffset.Now - dotNet8Released;
Console.WriteLine($"It has been {dotNet8Since.Humanize()} since .NET {net80.Version} was released.");

var dotNet9Released = DateTimeOffset.Parse(net90.Release);
TimeSpan dotNet9Since = DateTimeOffset.Now - dotNet9Released;
Console.WriteLine($"It has been {dotNet9Since.Humanize()} since .NET {net90.Version} was released.");

var dotNet10Released = DateTimeOffset.Parse(net10.Release);
TimeSpan dotNet10Since = DateTimeOffset.Now - dotNet10Released;
Console.WriteLine($"{dotNet10Since.Humanize()} since .NET {net10.Version} release.");

Console.WriteLine();

// Zeichne Balken für die Anzahl der Tage seit der Veröffentlichung
var bar = new BarChart()
    .Width(100)
    .AddItem("Days since .NET 8.0 release", dotNet8Since.TotalDays, Color.Red)
    .AddItem("Days since .NET 9.0 release", dotNet9Since.TotalDays, Color.Blue)
    .AddItem("Days since .NET 10.0 release", dotNet10Since.TotalDays, Color.Purple);
AnsiConsole.Write(bar);

Console.WriteLine();

// Lokale Funktion
static (Data, Data, Data) GetData()
{
    var net80 = new Data
    {
        Version = "8.0",
        Release = "2023-11-14"
    };
    var net90 = new Data
    {
        Version = "9.0",
        Release = "2024-11-12"
    };
    var net10 = new Data
    {
        Version = "10.0",
        Release = "2025-11-11"
    };
    return (net80, net90, net10);
}

// Datenklasse
class Data
{
    public required string Version { get; set; }
    public string Release { get; set; }
}

(rme)

Cloudflare hat EmDash als Preview veröffentlicht, ein Open-Source-CMS mit einem Fokus auf Sicherheit. Das Unternehmen schickt es als den „geistigen Nachfolger“ des seit über 20 Jahren bestehenden WordPress ins Rennen. EmDash zeichnet sich dadurch aus, dass es Plug-ins in einer eigenen Sandbox ausführt, um die Sicherheit zu erhöhen. Integrierte KI-Funktionen dürfen ebenfalls nicht fehlen.

EmDash ist serverlos, lässt sich jedoch auf eigener Hardware oder einer Plattform nach Wahl ausführen. Das Fullstack-Content-Management-System (CMS) ist in TypeScript geschrieben und nutzt unter der Haube das Open-Source-Webframework Astro, dessen Hersteller Astro Technology Company erst Anfang des Jahres von Cloudflare übernommen wurde. Benannt ist das CMS nach dem Geviertstrich (—), der unter anderem in der englischen Typografie als Gedankenstrich verwendet wird.

Plug-ins in eigener Sandbox

Wie Cloudflare in seinem Blog beschreibt, haben 96 Prozent aller Security-Probleme in WordPress ihren Ursprung in Plug-ins. In EmDash läuft daher jedes Plug-in innerhalb seiner eigenen, isolierten Sandbox. Dazu kommt die Cloudflare-Technologie Dynamic Workers zum Einsatz. Ein Plug-in erhält seine Fähigkeiten in EmDash via Bindings und kann ausschließlich die im Manifest des Plug-ins explizit deklarierten Aktionen durchführen. Das soll Entwicklerinnen und Entwicklern bereits vor der Installation die Gewissheit geben, welche Befugnisse eine Erweiterung haben wird.

Plug-ins für EmDash können zudem eine beliebige Lizenz haben, da sie von EmDash unabhängig sind. Das soll einen Marketplace-Lock-in verhindern. WordPress-Erweiterungen unterliefen dagegen aus Sicherheitsgründen einer manuellen Review und seien eng mit WordPress-Code verwoben. Daher würde teils argumentiert, dass die WordPress-GPL-Lizenz genutzt werden müsse, so Cloudflare.

Integrierte KI-Features

Als „KI-natives CMS“ angepriesen, bietet EmDash einige Features für die Nutzung künstlicher Intelligenz. EmDash-Instanzen enthalten Agent Skills und bieten einen integrierten Remote-MCP-Server (Model Context Protocol). Auch befähigt das EmDash-CLI KI-Agenten dazu, mit lokalen oder Remote-Instanzen von EmDash zu interagieren. Darüber lassen sich beispielsweise Medien hochladen, Inhalte durchsuchen oder Schemas erstellen und verwalten.

Auf verschiedene Arten können Entwicklerinnen und Entwickler ihre WordPress-Seiten in EmDash importieren. Um mit EmDash loszulegen, sind drei Starter-Templates enthalten: Blog, Marketing und Portfolio. Das Admin-Interface von EmDash können Interessierte in einem Playground ausprobieren.

Im GitHub-Repository ist der Quellcode des MIT-lizenzierten Projekts zu finden, das sich derzeit in der Beta-Preview-Version 0.1.0 befindet. Weitere Informationen zu EmDash teilt der Hersteller Cloudflare in seinem Blog mit.

(mai)