Mastodon
Zuletzt aktualisiert am
Übersetzung 🇬🇧 Volker Krause

Testen der First-Use-Experience von Anwendungen

Bei der Arbeit an einer Anwendung ist es nicht ungewöhnlich, dass man mit seiner eigenen Konfiguration und seinen eigenen Daten testet, und das oft in einer Power-User-Konfiguration der Anwendung. Das hat zwar Vorteile, aber man verliert leicht aus den Augen, wie die Anwendung aussieht und sich verhält, wenn sie zum ersten Mal in einer sauberen Umgebung geöffnet wird. Eine Übersetzung von 🇬🇧 Volker Krause.

Prüfung in einer sauberen Umgebung

Das Testen der ersten Nutzungserfahrung ist technisch einfach: Sie müssen nur den gesamten Anwendungsstatus und die Konfiguration löschen oder ein neues Benutzerkonto erstellen. Das ist jedoch sehr mühsam und wird daher nicht regelmäßig durchgeführt. Zum Glück gibt es bequemere und weniger invasive Abkürzungen.

Isolated XDG Environment

Bei vielen Anwendungen kommt man schon sehr weit, wenn man die XDG-Verzeichnisse trennt.

Das bedeutet, dass wir vier neue Verzeichnisse anlegen und die folgenden Umgebungsvariablen auf eines dieser Verzeichnisse verweisen:

  • XDG_CACHE_HOME (cached data)
  • XDG_CONFIG_HOME (configuration files)
  • XDG_DATA_HOME (application data)
  • XDG_STATE_HOME (application state)

Wenn eine Anwendung in einer solchen Umgebung ausgeführt wird, sieht sie nichts von ihrem bestehenden Zustand und ihrer Konfiguration (ohne diese zu zerstören). Das heißt, solange der gesamte Zustand und die Konfiguration tatsächlich an diesen Orten gespeichert sind.

Eine etwas häufigere Ausnahme ist die Speicherung von Anmeldeinformationen in einem Plattformdienst wie Secret Service oder KWallet. Diese sind nicht isoliert, und je nach Anwendung erhalten Sie möglicherweise keinen sauberen Erstverwendungsstatus oder Sie riskieren, den bestehenden Status zu beschädigen.

Multi-instance Akonadi

Auch andere Dienste, die von einer Anwendung genutzt werden, bedürfen möglicherweise besonderer Aufmerksamkeit. Ein besonders komplexer Dienst in diesem Zusammenhang ist Akonadi, da er viele Konfigurationen, Zustände und Daten enthält.

Glücklicherweise verfügt Akonadi über eingebaute Unterstützung für die Ausführung mehrerer isolierter Instanzen aus genau diesem Grund. Wir müssen lediglich die Umgebungsvariable AKOANDI_INSTANCE auf einen eindeutigen Namen setzen, und schon haben wir unsere eigene separate Instanz.

Automation

Mit den oben genannten Bausteinen können wir ein kleines Wrapper-Skript erstellen, das eine bestimmte Anwendung in einer sauberen ephemeren Umgebung startet:

import os
import subprocess
import sys
import tempfile

xdgHome = tempfile.TemporaryDirectory(prefix='testing-')
for d in ['CACHE', 'CONFIG', 'DATA', 'STATE']:
    os.mkdir(os.path.join(xdgHome.name, d))
    os.environ[f"XDG_{d}_HOME"] = os.path.join(xdgHome.name, d)

os.environ['AKONADI_INSTANCE'] = 'testing'

subprocess.call(sys.argv[1:])

subprocess.call(['akonadictl', '--instance', 'testing', 'stop', '--wait'])
xdgHome.cleanup()

Ich verwende dies seit einiger Zeit bei Itinerary, und es wurde mit der Einführung von Appium-based UI Tests zusätzlich nützlich, da diese in einer ähnlich isolierten Umgebung laufen.

Wenn Sie etwas etwas Längerlebiges benötigen, ist der Start einer Shell mit diesem Wrapper ebenfalls möglich. Damit können Sie dann Ihre Anwendung mehrfach starten, z.B. um zu testen, ob Änderungen korrekt persistiert werden.

Beschränkungen

Es gibt jedoch ein ungelöstes Problem bei der Isolierung von Anwendungen: D-Bus. Anwendungen, die einen eindeutigen D-Bus-Dienstnamen beanspruchen, können auf diese Weise nicht neben einer zweiten Instanz laufen, so dass Sie eine bereits laufende Instanz während des Testens herunterfahren müssen. In den meisten Fällen ist das keine große Sache, aber ziemlich lästig, wenn Sie an einer Ihrer Hauptkommunikationsanwendungen arbeiten.

Ich habe mir zwei Möglichkeiten angesehen, D-Bus zu isolieren (beide sind relativ einfach in ein Wrapper-Skript zu integrieren):

  • xdg-dbus-proxy Dies kann den Zugriff auf bestimmte Hostdienste einschränken, bietet aber keine Möglichkeit, eine zweite isolierte Instanz eines Dienstes zu haben.
  • Einen separaten D-Bus-Sitzungsbus betreiben: Eine zweite Instanz eines Dienstes zu haben, ist dann kein Problem, aber wir haben keine Möglichkeit mehr, auf Host-Dienste zuzugreifen (d. h. auch keinen Dienst zur Speicherung von Anmeldeinformationen usw.).

Beides ist bei den Anwendungen, an denen ich arbeite, nicht hilfreich, kann aber in anderen Szenarien durchaus praktikabel sein.

💡 Je mehr eine Anwendung in den Plattformstatus verstrickt ist, desto schwieriger wird es, diese Art der Isolierung zu erreichen, und desto mehr muss man die Vorgehensweise anpassen. Es zahlt sich aber schnell aus, denn eine einfache und jederzeit verfügbare Möglichkeit, Dinge schnell in einem sauberen Zustand zu testen, ist sehr hilfreich.

Comments