Florent Destremau discute de l'utilisation des DTO (Data Transfer Objects) dans les formulaires, soulignant que leur utilisation est souvent présentée comme une évidence sans considérer le contexte et le coût de maintenance. Il illustre cela avec un exemple simple où l'ajout d'un DTO et d'un service de mapping pour une entité basique crée une sur-complexité et une duplication de code. Il argue que pour des opérations CRUD simples, les DTO n'apportent que peu de valeur et recommande plutôt d'écrire des tests pour protéger le code. Il montre comment déplacer les contraintes de validation sur l'entité et utiliser du typage strict peut simplifier le code tout en maintenant une bonne robustesse. Il conclut que cette approche résulte en un couplage plus souple et une couverture de test accrue, malgré une perception initiale de moins de rigueur.
Cet article de Sebastian Bergmann explique les différences entre les Data Transfer Objects (DTOs) et les Value Objects, et pourquoi l'immutabilité facilite les tests. Les DTOs, motivés techniquement, servent à transférer des données entre couches ou systèmes, tandis que les Value Objects, motivés par le domaine, représentent des concepts stables du domaine. L'immutabilité réduit la charge cognitive en test, car elle garantit que l'état des objets ne change pas. Les Value Objects, étant immuables, n'ont pas besoin de test doubles, contrairement aux DTOs qui peuvent en nécessiter si ils contiennent de la logique. L'utilisation d'objets immuables simplifie les tests en évitant les effets de bord indirects.
L'article explique comment tester la documentation OpenAPI avec PHP pour garantir que le comportement d'une API correspond à sa documentation. Il propose d'intégrer la validation OpenAPI dans des tests fonctionnels en utilisant la bibliothèque league/openapi-psr7-validator. L'approche consiste à créer une classe abstraite qui facilite la vérification des requêtes et réponses HTTP par rapport à la spécification OpenAPI. Cela permet de maintenir la cohérence entre le code et la documentation tout au long du développement, améliorant ainsi la qualité et la fiabilité de l'API.
Si le composant Lock de Symfony pose quelques problèmes dans les tests unitaires, on peut essayer de configurer env.test ainsi : soit LOCK_DSN=null soit LOCK_DSN=in-memory
L'article explique comment Zenstruck Foundry a révolutionné les tests dans Symfony en permettant de créer des données de test de manière simplifiée et expressive. Cette bibliothèque utilise des factories pour générer rapidement des données pour les entités Doctrine, supporte Faker pour des données aléatoires réalistes, et intègre des fonctionnalités comme les "stories" pour définir des scénarios de données réutilisables. Foundry est particulièrement utile pour tester des modèles de domaine complexes, y compris les Value Objects et les Aggregates en Domain-Driven Design (DDD), en simulant des interactions réalistes sans la complexité de gérer les données sous-jacentes
.
L'auteur se place dans le contexte d'une application Symfony avec des tests PHPUnit et en fournissant des jeux de données via Foundry. Il montre l'utilisation du trait ClockAwareTrait et composant Clock. Enfin, il rappelle que PHP-FIG a proposé la PSR-20 Clock qui dispose de plusieurs implémentations, dont le composant Clock.
L'article compare les tests unitaires au jeu Cluedo, où chaque ligne de code est un suspect potentiel. En utilisant PHPUnit, les développeurs peuvent identifier les bugs comme des crimes à résoudre. L'article explique comment les tests, notamment avec PHP 8.4, permettent de vérifier chaque combinaison possible pour éviter les erreurs en production. Le Test-Driven Development (TDD) est présenté comme une méthode préventive, où les tests sont écrits avant le code pour anticiper les problèmes. L'article souligne l'importance des mocks et des doublures pour simuler les dépendances externes et assure que les tests sont essentiels pour maintenir la qualité du code et dormir tranquille.
Une série de 3 articles sur pytest, le framework de test Python de référence
Tout est dans le titre
Tout est dans le titre
Un excellent article sur l'usage des différentes doublures de test : mocks, spys, stubs, fakes et dummies
pour rappel, DBT est présenté https://blog.ippon.fr/2022/01/07/testez-votre-code-sql-avec-dbt/
Pour résumer, lorsqu'un test échoue, toutes les infos nécessaires doivent être disponibles dans le message d'échec
Rappel : DBT fait partie des ELT (extract, load & transform), notamment pour le "T" - cf https://blog.ippon.fr/2020/10/23/decouvrez-dbt/
DBT 1.8 supportera nativement les tests unitaires de modèles - l'auteur montre comment les mettre en place en utilisant le TDD
L''article montre comment rendre les tests moins sensibles aux détails d'implémentation
Tout est dans le titre
Un conseil pour les tests unitaires : avoir des tests/assertions au scope le plus restreint possible pour être moins sensible au changement
Tout est dans le titre
Tout est dans le titre