Floci : définir ce que le test local peut prouver

Un worker reçoit un message, enregistre le résultat puis tombe avant de supprimer le message. Un test local utile doit montrer la prochaine livraison et vérifier si l'effet a été répété. La réussite d'une création de file dit peu de choses sur cette panne.

C'est le scénario que je proposerais pour Floci, un émulateur AWS open source. Cette revue des sources a été vérifiée le 6 novembre 2026. Je n'ai installé aucun logiciel, comparé aucun résultat avec AWS ni mesuré les performances. Les essais proposés sont mon analyse, pas des expériences réalisées.

Lire le détail du service

Le dépôt distingue les services exécutés dans le processus et les chemins utilisant de vrais conteneurs Docker pour des bases, protocoles ou environnements d'exécution. Un moteur réel ne reproduit pourtant pas tout le service managé. La ligne Aurora DSQL précise que son implémentation PostgreSQL ne reproduit pas encore les limites de DSQL et ses index asynchrones.

Je transformerais donc la liste de couverture en questions sur les appels effectivement utilisés. Pour la file : envoyer un message synthétique, le recevoir, enregistrer un résultat synthétique et acquitter la livraison. Noter les opérations et attributs nécessaires permet ensuite de comparer une mise à jour de l'émulateur à un contrat précis.

Rendre la destination explicite

Les exemples SDK utilisent une adresse locale avec de faux identifiants. Un test ne devrait pas hériter silencieusement d'un profil de production. Ce court exemple original vérifie seulement une chaîne d'adresse. Il ne démarre aucun service, n'isole pas le réseau et ne configure pas la file.

from urllib.parse import urlsplit

def require_local_endpoint(endpoint):
    u = urlsplit(endpoint)
    if (u.scheme != "http" or u.hostname != "127.0.0.1"
            or u.port != 4566 or u.username or u.password
            or u.path not in ("", "/") or u.query or u.fragment):
        raise ValueError("Expected the explicit loopback test endpoint")
    return endpoint

Cette restriction est volontairement étroite : un autre nom de conteneur sera rejeté. Un essai conteneurisé exige sa propre configuration réseau vérifiée. Le choix important est l'arrêt si la destination attendue manque, sans bascule implicite vers un compte réel. Les données et clés de production restent hors du scénario.

Choisir la panne puis l'observation

Je séparerais l'acquittement normal, la panne avant acquittement, la répétition d'un identifiant métier, la requête invalide et l'opération interdite avec les contrôles activés. Ce sont des tests proposés, pas des cas dont j'affirme la réussite dans Floci. Chacun exige un résultat attendu, un délai et un compte des effets de l'application.

Message synthétique → file → worker → écriture
                                |
                         panne avant acquittement
                                |
                       nouvelle livraison → compter les effets

Contrat retenu → comparaison AWS séparée et autorisée

Si la règle métier impose un seul résultat par identifiant malgré plusieurs livraisons, il faut inspecter ce résultat stocké. Le code de sortie du worker ne suffit pas. Deux passages heureux successifs peuvent ne jamais exercer l'intervalle entre écriture et acquittement.

Les permissions sont un test distinct

La documentation multi-compte explique qu'un identifiant de clé à douze chiffres sélectionne l'espace du compte. Les autres formats utilisent le compte par défaut. La validation des signatures est désactivée par défaut. Le référentiel des variables indique aussi que l'application des politiques IAM est désactivée par défaut.

L'isolation de deux espaces ne prouve donc pas le refus d'une fausse signature ou d'une action interdite. Le test de permissions doit inclure un refus et conserver la configuration des contrôles avec le résultat. Routage, signature et politique sont des propriétés séparées.

État et accès à l'hôte

Le guide du stockage décrit memory, persistent, hybrid et WAL. Selon le README, memory perd les données à l'arrêt, persistent écrit immédiatement, hybrid effectue des sauvegardes périodiques et WAL journalise les mutations avant de répondre. Ce sont les choix documentés du projet, pas une mesure indépendante de durabilité.

Une file propre exige un cycle de vie choisi. Un test de reprise exige une frontière de redémarrage et l'inspection des données. Les chemins Docker demandent le socket Docker. Je commencerais le test simple sans cet accès et réserverais le contrôle des conteneurs au scénario qui en a besoin, dans un environnement jetable.

Mon critère de choix

La licence MIT permet la réutilisation avec ses obligations de notice et sans garantie. Le dépôt présentait une activité le 5 novembre. Ces faits ne prouvent pas la fidélité. Épingler une version, garder une matrice de comportements et autoriser séparément les vérifications AWS importantes, avec leurs coûts et leur nettoyage, donne au résultat vert une portée lisible. Les limites non testées doivent rester visibles à côté.