Qu'est-ce qui vaut la peine d'être testé dans un modèle/une entité ActiveRecord?

Question

Je viens juste de commencer les tests unitaires et je suis un peu confus et un peu débordé quand le sujet teste les modèles. J'ai actuellement des modèles ActiveRecord avec setters et getters. La plupart d'entre elles consistent simplement à encapsuler des données, seules certaines d'entre elles apportent quelque chose de nouveau, comme par exemple une méthode getFullName() qui retourne la concaténation des champs firstName et lastName.

Alors, que dois-je tester? Dois-je tester chaque affectation de propriété ou dois-je tester uniquement les méthodes spéciales comme getFullName()? Dans quelle mesure devrais-je aller? Quand dois-je tester la classe elle-même et quand devrais-je réellement tester l'insertion de la base de données? Qu'en est-il de la validation déjà présente dans l'entité, devrais-je en tenir compte? Ce qui me dépasse est le nombre de tests dont il me semble avoir besoin pour une entité avec beaucoup de champs. Y a-t-il un moyen de contourner cela?

Des exemples seraient particulièrement appréciés!

Answer 1

Écrivez les tests dont vous avez besoin pour vous assurer que votre programme fonctionne correctement. Il y a des gens qui diraient que si la classe n'a pas de logique métier, il n'est pas nécessaire d'écrire des tests pour celle-ci. Par cet argument, vos simples getters et setters n'ont pas besoin d'être testés. Vous écrivez uniquement des tests pour les parties du code qui ont une «logique métier». Cependant, l'autre côté de l'argument est que si vous écrivez le code, vous devriez écrire un test pour celui-ci. Par cet argument, vous devriez écrire un test pour eux. Le test finira par être vraiment trivial. Vous instanciez l'objet, définissez une valeur avec le setter, puis affirment que la valeur est renvoyée avec getter. Vous vous retrouvez avec beaucoup de tests simples et cela peut devenir fastidieux d'écrire. Je suis dans le deuxième camp et j'ai constaté que si quelque chose est difficile à tester ou devient difficile à tester, c'est un signe que j'ai un problème avec mon design. Dans ce cas, vous pouvez avoir des méthodes accesseur pour les choses qui ne sont pas nécessaires. Ce qui s'est probablement passé est que vous avez toutes vos propriétés dans votre objet de données et que vous avez besoin d'un getter et d'un setter pour chacun d'entre eux. Mais vous vraiment? Dans votre question, vous avez mentionné que vous avez une méthode getFullName. Alors avez-vous vraiment besoin de méthodes pour getFirstName et getLastName? Pourquoi les données de l'objet changeraient-elles pendant le rendu de la page? Pourquoi ne pas renoncer aux setters et rendre l'enregistrement de données 'immuable' afin qu'une mise à jour soit faite en envoyant un nouvel objet à la base de données pour la mise à jour/créer? Je parierais que la raison pour laquelle vous avez cette question est que vous avez écrit ce code et essayez maintenant de revenir en arrière et d'écrire des tests pour cela. Vous avez cet objet de données et des getters et setters créés automatiquement pour tout. Puis écrit des méthodes supplémentaires dont vous avez besoin pendant que vous l'utilisiez (comme la méthode getFullName). Je recommanderais plutôt que vous ne créiez les accesseurs que lorsque vous en auriez besoin. Ensuite, vous créez le test à ce moment-là et vous constaterez que la liste des fonctions est sensiblement plus petite. Vous pouvez avoir une poignée de méthodes qui obtiennent les combinaisons de données dont vous avez besoin ainsi qu'une méthode en masse pour obtenir toutes les données dans un formulaire particulier (ie json).