Comment contourner Fitnesse SetUp/TearDown pour un test individuel?

Question

Nous utilisons Sélénium et Fitnesse pour les tests d'interface utilisateur, où nous ouvrons Firefox et exécuter toutes les actions liées à l'interface utilisateur - cliquez, remplissez les champs, bouton de presse, etc.

Dans le cadre de notre cadre de test actuel, FitnesseRoot a le SetUp/TearDown défini, pour ouvrir/détruire l'instance du navigateur. Toutes les suites et les tests (environ 300) utilisent SetUp/TearDown dans le cadre du test de l'interface utilisateur. J'essaie de remplacer l'un de nos tests simples par de nouveaux appareils pour les tests API, car les tests API sont bien plus rapides que les tests d'interface utilisateur. Le test lui-même fonctionne bien, mais le problème ici est que même si mes appareils REST ne nécessitent pas d'instance de navigateur, SetUp l'ouvre et TearDown essaie de le fermer, mais renvoie une exception (puisque le test en cours pointe vers la classe de pilote API , alors que les méthodes dans TearDown appartiennent à la classe UI Driver).

Je ne peux pas supprimer le SetUp/TearDown, car il a un impact sur 300 cas de test, comme mentionné ci-dessus. Est-il possible que je puisse empêcher un test spécifique d'utiliser SetUp/TearDown? Ou renvoyer le TearDown à la classe de pilote d'interface utilisateur, afin que le test ne lève pas une exception?

SetUp:

|import   | 
|com.myapplication.fitnesse.ui| 
|com.myapplication.util.restclient.fixtures| 

!define slim.flags {-s 200} 

!|script |                       
|start| my UI driver class|${SERVER}|${PORT}|FIREFOX|${PAGE_PATH}.${PAGE_NAME}|${PROXYSERVER}| 
|debug mode   |false |  

test réel:

!define TEST_SYSTEM {slim} 
| script | my API driver class | server ip:port | username | password| 
| login | 
| do something...| 

TearDown:

|script    | 
|logout    | 
|destroyDriver  | 

Answer 1

Merci pour votre réponse, mais au lieu de distribuer les tests effectués dans des suites, j'ai utilisé ce qui suit pour changer les pilotes:

SetUp => | scripts | | début | mon classe de pilote d'interface utilisateur | $ {SERVER} | $ {PORT} | FIREFOX | $ {PAGE_PATH}. $ {PAGE_NAME} | $ {PROXYSERVER} | | mode de débogage | false | | $ my_UI_DRIVER = | get fixture | Test réel => ! Define TEST_SYSTEM {slim} | script | mon cours de pilote API | serveur ip: port | nom d'utilisateur | mot de passe | | connexion | | faire quelque chose...|

TearDown => | script | $ my_UI_DRIVER | | déconnexion | | destroyDriver | SetUp ouvre le navigateur tel que mentionné dans la classe de pilote de l'interface utilisateur. Mon test Fitnesse pointe vers la classe de pilote d'API et exécute mon test. TearDown pointe vers la classe de pilote de l'interface utilisateur et ferme le navigateur. Par conséquent, mon test fonctionne correctement sans aucune erreur/exception. De cette façon, je peux combiner API et interface utilisateur en un seul test.

Answer 2

Ce que je tends à faire est d'organiser mes tests en suites: une extrémité avant et arrière un par exemple. Ceux de l'extrémité avant obtiennent une configuration qui démarre le sélénium, ceux de l'arrière ne l'obtiennent pas. Donc, la configuration n'est pas au niveau de la racine, mais (au moins) une baisse.

En fait, j'ai tendance à démarrer le sélénium dans une SuiteSetUp plutôt que dans une configuration et à réutiliser le pilote entre les tests. Je trouve que cela accélère les tests un peu. La fermeture du pilote est ensuite effectuée dans SuiteTearDown. Les suites imbriquées peuvent remplacer le SuiteSetUp (et SuiteTearDown) d'un parent en définissant le leur.

Je suppose que cela fonctionne également dans votre situation. Définissez une (ou plusieurs) suites séparées pour les tests API et donnez à ces suites une configuration et un démontage sans sélénium. Je ne l'ai pas essayé mais je m'attends à ce que l'installation et le démontage des parents soient ignorés dans ce cas.