Le contexte
Je continue un code hérité pour un jeu dans Unity3d, et je veux écrire des tests fonctionnels destinés à la régression, pour m'assurer de ne pas casser les choses lors de l'implémentation de nouvelles choses ou lors de la refactorisation.
Je sais déjà que la suite «Unit Test Tools» pour Unity3d est disponible en tant qu'actif. Je l'ai utilisé comme suite de tests unitaires, donc je teste mes modèles (classes).
Exemple du type de test auquel je pense
Par "test fonctionnel", je veux dire des choses comme ceci:
- Exécutez le programme
- Dans la scène du menu, affirmez qu'il y a un bouton qui dit "démarrer"
- Cliquez dessus
- Puis affirmez qu'une nouvelle scène est chargée
- Affirmez que le pixel XXX est rouge
- Cliquez dans la coordonnée XXX
- Affirmez maintenant que le pixel est devenu vert
- etc.
Des questions
Q1: Comment écrire et exécuter des tests fonctionnels pour mon jeu? Cela se fait-il généralement dans les UnityTestTools (UTT)?
Q2: Si UTT est davantage destiné aux tests unitaires, existe-t-il une suite distincte pour les tests fonctionnels? Laquelle?
Remarques:
Je cible Android et je cours Unity5.3.1f1
la source
Réponses:
Si je comprends bien, vous cherchez à comprendre les tests d'automatisation dans Unity.
Outils de test Unity
Cela devrait être votre méthode goto, mais avant de creuser comment, j'examinerai le pourquoi.
La façon préférée d'effectuer toute forme de test d'automatisation est de le faire dans un environnement aussi proche de la production que possible. Utiliser quelque chose comme les outils de test Unity (vivant dans l'éditeur Unity) semble être une mauvaise idée pour quiconque a écrit des tests d'intégration conventionnels.
Pourquoi? Parce qu'avec tout test d'intégration, vous voulez que le moins de choses supplémentaires embourbent votre application qui n'est pas là lorsque l'utilisateur l'ouvre. L'éditeur Unity peut avoir des performances ou un comportement différents par rapport à la version iOS (par exemple).
Alors, pourquoi utiliser les outils de test Unity (UTT)?
La raison principale est la commodité. L'éditeur Unity et UTT sont conçus pour être faciles à utiliser et visuels. Vous aurez du temps à écrire des tests, à les accrocher à votre jeu spécifique et à comprendre quand ils échouent.
Qu'en est-il de la différence de comportement entre l'éditeur Unity et la production?
Après tout, l'éditeur Unity est un wrapper autour de votre application. Cela signifie qu'il y aura des différences entre l'éditeur et la production. Mais, mis à part les tests d'intégration, l'éditeur Unity est un wrapper depuis très longtemps maintenant. C'est une plate-forme mature avec des milliers de jeux construits sur elle. Les résultats obtenus en exécutant des tests d'intégration dans l'éditeur seront très précis.
Dans l'exemple de scénario que vous avez fourni, tout sauf le premier élément peut facilement être affirmé à l'aide des outils de test Unity. Vous pouvez ouvrir des scènes et valider des comportements comme tout autre test d'intégration.
Je suggère d'écrire la plupart (sinon la totalité) de vos tests en utilisant UTT. Pour ajouter la compatibilité avec les outils d'intégration continue (par exemple Jenkins), vous voudrez peut-être les exécuter à partir de la console en utilisant des arguments de ligne de commande .
Démarrage de l'application et test manuel
Le démarrage de l'application n'est pas quelque chose que vous avez un contrôle précis lorsque vous êtes dans l'éditeur Unity. Pour valider cet aspect de votre jeu et plus encore, vous pouvez utiliser des tests manuels de base.
Voici comment aborder cela:
Alternatives
Sans surprise, comme tout ce qui concerne Unity, nous avons plus que quelques alternatives. Voici quelques-uns que vous voudrez peut-être considérer:
Selon l'échelle et la portée de votre projet, vous souhaiterez peut-être utiliser une ou plusieurs des options décrites ci-dessus.
la source