Plusieurs niveaux de setUp/tearDown dans TestNG?

Question

En utilisant TestNG pour mon framework Selenium, la méthode setUp est relativement complexe. Il y a plusieurs points qu'il peut casser et je voudrais le diviser en étapes séparées.

Idéalement, il ressemblerait à quelque chose comme ceci:

// Does some DB stuff, logs some messages 
@BeforeMethod(alwaysRun = true) 
preTestCase 


// Instantiates and opens up Selenium 
@BeforeMethod(dependsOnMethods = {"preTestCase"}) 
seleniumSetup 


// Closes Selenium only if it was properly setup 
@AfterMethod(dependsOnMethods = {"seleniumSetup"}) 
seleniumTearDown 


// All other test case teardown, error logging 
@AfterMethod(alwaysRun=true) 
postTestCase 

Ce que je veux éviter est un échec dans preTestCase en raison d'un problème DB et obtenir un échec secondaire en raison de seleniumTearDown essayant de fermer une instance inexistante . Dans cette situation, seul postTestCase doit être exécuté. J'obtiens cette erreur: seleniumTearDown() n'est pas autorisé à dépendre du public seleniumSetUp (org.testng.ITestContext). Est-ce que ce n'est pas permis/mauvais design? Comment puis-je appliquer l'ordre d'exécution entre les deux méthodes tearDown afin que postTestCase() soit toujours exécuté en dernier, indépendamment du fait que seleniumTearDown soit exécuté?

Answer 1

Votre modèle semble un peu humide, installation et démontage ne devrait pas échouer. Bien qu'ils pourraient éventuellement non-op. Un péché; "Tentative de faire une connexion db, n'était pas disponible, donc rien à la place" puis en démolissant vous devriez vérifier s'il s'agit d'une connexion avant de tenter de le fermer.

Sinon, si vous souhaitez conserver votre modèle actuel, vous pouvez utiliser une sorte de vérification manuelle au lieu de l'annotation (une classe booléenne ou singleton fonctionnerait).

In Setup: 
if(dbGetConnected()) { 
.... 
} else { 
    dbisntconnected = true; 
} 

In tearDown: 
if(!dbisntconnected) { 
    dbClose(); 
} 

Answer 2

L'erreur que vous voyez est parce que vous essayez d'avoir une @AfterMethod dépendre d'un @BeforeMethod, qui n'a pas de sens. Vous pouvez faire en sorte que les méthodes de configuration dépendent les unes des autres, mais elles doivent toutes être du même type (par exemple, tous les @AfterMethod ou tous @BeforeMethod). En ce qui concerne votre autre problème, la solution proposée par Valchris est ce que je recommande. Si vous savez que vos tests ou configurations sont fragiles mais qu'ils ne doivent pas interrompre le test, attrapez l'exception vous-même afin que TestNG ne la voie jamais.