DEV Community: Raphaël Anic-Antic

Authentification Oauth2 avec OpenFeign

Raphaël Anic-Antic — Tue, 17 Oct 2023 19:47:10 +0000

Contexte

OpenFeign est une libraire du projet Spring Cloud permettant de développer des clients HTTP de manière déclarative.

Note : Spring Cloud OpenFeign n'est pas à confondre avec Feign. En effet, le premier est une surcouche du second offrant une integration au reste de l'écosystème Spring

Dans cet article, nous allons voir comment configurer OpenFeign pour gérer une authentification Oauth2 de manière transparente en se basant sur l'autoconfiguration de Spring Security

Spring Security

Spring Security permet de gérer l'authentification Oauth2 à un service via son autoconfiguration.
Pour se faire, un simple configuration de propriétés dans le fichier application.properties est nécessaire :

spring.security.oauth2.client.registration.XXX.client-id=${client_id}
spring.security.oauth2.client.registration.XXX.client-secret=${client_secret}
spring.security.oauth2.client.registration.XXX.authorization-grant-type=client_credentials
spring.security.oauth2.client.registration.XXX.scope=${scope_list}
spring.security.oauth2.client.provider.XXX.token-uri=${token_uri}

XXX représente le nom du clientRegistrationId utilisé par Spring Security et OpenFeign.

Vous pouvez lui donner le nom de votre choix. D'autre part, vous pouvez configurer différentes authentification Oauth2 en utilisant différents clientRegistrationId

La configuration ci dessus active l'authentification Oauth2 pour Spring Security et RestTemplate (client HTTP par défaut de Spring).

Cependant, nous souhaitons utiliser OpenFeign et pas RestTemplate.

OpenFeign

OpenFeign étant une librairie du projet Spring Cloud, elle dispose de configuration lui permettant de s'intégrer au reste du framework Spring (donc Spring Security).

Pour activer cette intégration, les deux lignes suivantes doivent être ajoutées à votre fichier application.properties

spring.cloud.openfeign.oauth2.enabled=true
spring.cloud.openfeign.oauth2.clientRegistrationId=XXX

Nous retrouvons ici le fameux clientRegistrationId. Celui ci doit être le même que celui configuré pour Spring Security.

Grace à cette configuration, OpenFeign peut gérer automatiquement l'authentification Oauth2 ainsi que le rafraichissement de token.

GWT : une astuce simple pour des tests simples

Raphaël Anic-Antic — Tue, 17 Oct 2023 18:46:06 +0000

Dans cette série de posts sur l'assurance qualité, je voulais vous partager un format simple à mettre en place pour rendre vos tests plus lisibles et potentiellement détecter des erreurs de conception.

Given When Then

Given When Then (ou GWT) est un format simple qui définit les trois étapes obligatoires d'un test.

En effet, lorsque nous rédigeons un test, nous implémentons toujours les trois mêmes étapes :

Mise en place de l'état du système (initialisation)
Action sur le système (exécution)
Observation du nouvel état du système (assertion)

Les sources de notre test peuvent représenter ces trois étapes en les divisant par de simples commentaires :

// Given
Person p = new Person("john", "Doe", 22);
PersonService service = new PersonService();

// When
boolean isAdult = service.isAdult(p);

// Then
assertThat(isAdult).isTrue();

Given

Cette partie regroupe toutes les étapes nécessaires à l'initialisation du test. Elle décrit l'état du système précédant l'exécution.

Cette partie peut être vide (ex : si notre système n'a pas d'état)
Si cette partie est grande et/ou complexe, alors cela peut :
- mettre en évidence un système trop complexe
- indiquer un périmètre de test trop grand.
- se traduire en un test instable (flaky)

When

Il s'agit de l'action sur le système. Généralement peut être résumée en un seul appel de méthode.

Si plusieurs appels de méthodes sont nécessaires pour rendre le test intéressant, alors cela peut signifier que
- le code à tester est trop complexe / factorisé
- le périmètre de test peut encore être réduit.

Then

Cette dernière rubrique contient toutes les assertions (vérifications) faites sur le système.

Un test avec une partie "Then" vide est un test inutile !

Conclusion

GWT est un format trivial à mettre en place qui peut grandement aider la rédaction de test et mettre en valeur les défauts de conception d'un système.
Toutefois, l'implémentation présentée ici n'est que la simplification du langage "Gerkhin" utilisé par l'outil "Cucumber".

Si vous souhaitez en savoir plus sur GWT, je vous invite à lire cet article de Martin Fowler.

QA - Définitions et théorie

Raphaël Anic-Antic — Tue, 17 Oct 2023 18:17:22 +0000

On dit Assurance ou Contrôle Qualité ?

En réalité, on peut dire les deux. Mais ces deux termes désignent des concepts différents !

Assurance qualité (QA)

définition : méthode visant à empêcher l'apparition d'erreurs et défauts dans un produit afin d'éviter des problèmes lors de sa livraison
objectif : examiner et modifier les procédés utilisés pour obtenir un produit final

Contrôle qualité (QC)

définition : processus utilisé pour certifier la qualité d'un produit ou d'un service par rapport à des exigences
objectif : examiner le produit ou service et vérifier qu'il réponds correctement aux exigences formulées

En ingénierie logicielle, le contrôle qualité consiste à tester du code (automatiquement ou non) tandis que l'assurance qualité vise à définir les méthodes et procédé utilisés pour limiter le risque de défauts pendant la production du code.

L'assurance qualité est une pratique qui s'inscrit sur l'ensemble de la pipeline de développements. Elle concerne tout les acteurs d'un projet.

Stratégies de tests

Une stratégie de test vise à définir l'objectif d'un test. Il ne faut pas la confondre avec un "type" de test (que nous aborderons plus tard).

Tests d'acceptation : vérifier le bon comportement d'une fonctionnalité et son respect de la spécification

Tests de non régression : vérifier l'absence d'impact d'un nouveau développement sur les fonctionnalités déjà présentes

Note : avec le temps, les tests d'acceptation deviennent des tests de non régression

Tests de caractérisation : caractériser et document le comportement d'une fonctionnalité mal connue.

Note : les tests de caractérisation peuvent être utilisés comme des tests de non régression sur des fonctionnalités non spécifiées ou legacy

SUT

définition : System Under Test. Système affecté par un test

Objectif : Le SUT permet de définir le périmètre d'un test. C'est à dire, l'objectif de ce dernier. Il est généralement préférable d'avoir le périmètre le plus réduit possible afin de faciliter la maintenance du test.

QA - Comment rédiger un test utile ?

Raphaël Anic-Antic — Tue, 17 Oct 2023 17:29:20 +0000

Dans cet article, nous allons nous intéresser à la valeur des tests automatisés. En effet, chaque test a une valeur et un cout.

C'est à dire, comment ils permettent de résoudre leurs problèmes métiers. La valeur ajoutée est elle systématique ? En tant que développeurs, comment pouvons nous rédiger les tests les plus utiles possibles ?

L'argent ne pousse pas sur les arbres. Les tests non plus

Chaque test a une valeur et un cout.

Sa valeur est représentée par sa capacité à réduire les risques lors des développements.
Son coût est est le temps de travail nécessaire à sa mise en place et à sa maintenance.

Le coût de maintenance ne doit pas être sous-estimé, un test complexe et prompt aux erreurs devra souvent être re-analysé et modifié.

Impact : un test qui détecte des bugs à impact fort a plus de valeur qu'un test qui détecte des bugs très mineurs.

Cela ne veut pas dire qu’il ne faut pas tester les bugs mineurs. Il faut cependant jauger le coût d'un test pour rester rentable.

NB: les tests manuels sont très onéreux car chaque exécution induit des coûts supplémentaires

Quels facteurs rendent un test plus ou moins rentable ?

Il existe plusieurs facteurs qui peuvent affecter la rentabilité d'un test.

L'objectif de cet article est de mettre en lumière les facteurs principaux et de tenter de fournir des solutions permettant de rendre nos tests plus rentables

Le diagnostique, c'est pas automatique

En cas d’erreur, le test doit être capable de décrire précisément le bug rencontré. Pour se faire, un test doit se concentrer sur un composant précis et le tester indépendamment.

Exemple : Dans un formulaire, tester le fonctionnement d’un champ en particulier sans se soucier de la valeur des autres champs (ie. y insérer des cas nominaux).

Cette notion est appelée le périmètre d'un test. Généralement, on souhaite créer un test avec le **périmètre le plus petit possible". De cette façon, si quelque chose casse, on sait exactement quoi.

Exemple d'un petit périmètre :

[Contexte]
J'ai un service backend qui récupère des montants notes de frais depuis une API externe, calcule le total Hors Taxes des montants et les enregistre en base de données.

Je souhaite rédiger un test automatisé qui vérifie que le calcul de total Hors Taxes est correct.

[Décision]
La valeur de ce test réside dans la vérification du calcul TTC -> HT. 
Vérifier le fonctionnement de l'API et de la BDD n'apportent aucune valeur à mon test. 

Je choisis de les exclure de mon périmètre de test.

Connaissez vous la définition de la folie ?

La folie c'est faire la même chose encore et encore et s'attendre à un résultat différent

Si vous avez déjà eu un test qui, entre deux exécutions, produit des résultats différents, alors vous êtes familier avec cette définition.

Il arrive qu'un tests puisse avoir des résultats différents entre plusieurs exécutions. On appelle ses tests "flaky tests" ("friables" ou "peu fiable" en français).

Ce type d'irrégularité peut apparaitre lorsque le périmètre du test est trop large (i.e. trop de variables entrent en jeu) ou si le scénario de test n'est pas assez précis.

Si vous rencontrez ce genre de problèmes, isolez les variables, simplifiez le test voir diviser le en plusieurs

Un test n'est rien d'autre qu'une spécification

Comme nous avons déjà pu le dire, un test permet de vérifier le bon comportement d'une fonctionnalité.

Cependant, son usage ne se limite pas là. Il peut aussi servir de documentation pour les équipes de développement. En spécifiant le comportement attendu, il jour aussi le rôle de... spécification.

Il est possible de faire gagner de la valeur à un test en le traitant comme une spécification. Un test peut paraphraser la spécification fonctionnelle et documenter, en détail, le comportement attendu.

Récapitulatif

Maintenant que nous avons abordé les notions théoriques affectant la valeur d'un test, je vous propose un court récapitulatif d'actions et de concepts à garder en tête pendant la rédaction de vos tests.

Note : ces instructions sont valables pour des tests automatisés ou manuels

Caractéristiques d'un "bon" test

A des instructions claires sur quand et comment l'exécuter
Spécifie le résultat désiré
Spécifie les résultats non désirés
Isole correctement la fonctionnalité testée (on sait d’où vient le bug)
Est basé sur les spécifications et non sur l’implémentation
Documente clairement son fonctionnement et son objectif. Si une fonctionnalité change, les tests liés doivent être modifiables simplement
Vérifie les comportements courants en premier

Caractéristiques d'un "mauvais" test

N’est pas documenté ou ne peut être exécuté que par quelqu’un familier avec la fonctionnalité testée
Donne des résultats non reproductibles
Ne couvre que les cas nominaux
Utilise une méthodologie différente du reste du catalogue de test
Nécessite des modifications de l’environnement qui ne sont pas réalistes (~ ne correspondent pas à la production)