0
votes

Comment puis-je appeler un test JUnit comme configuration pour un autre?

J'essaie de créer un test JUnit qui nécessite qu'un utilisateur se connecte avec un compte administrateur. Pour éviter d'avoir à répéter le code, j'ai effectué un test de Login JUnit et un test GoToAdminPage JUnit.

  • Le premier accède à la page de connexion et se connecte.
  • Le second tente d'atteindre un menu accessible uniquement par les administrateurs et est destiné à reprendre là où le premier s'arrête . Ce que je veux, c'est que GoToAdminPage démarre sur la même page et avec le même environnement que la Login se termine.

L'idée est qu'en créant un test automatisé de Login , je peux le réutiliser pour tout test que je veux faire à l'avenir et qui nécessite des droits d'administrateur.

Ce que j'essaye de faire est, dans le setUp() de GoToAdminPage , d'appeler le premier test. Cependant, cela lance un navigateur de test pour GoToAdminPage , puis lance immédiatement un autre navigateur de test pour Login qui se ferme puisque Login.tearDown() contient une instruction driver.quit() .

Ce que je veux, c'est que GoToAdminPage s'attend à reprendre directement sur la même page La Login se termine, il n'a pas d'instructions pour get donc il ne quitte jamais la page de départ de Firefox.

J'ai déjà essayé plusieurs choses. Chacun de mes tests hérite de la classe BasicTest , qui définit un certain nombre de choses (WebDriver, JS Executor, fonctions utilitaires génériques, etc.). Dans cette classe, j'ai créé une perform() qui appelle setUp() et test() .

De cette façon, dans GoToAdminPage , tout ce que je devrais faire est d'appeler Login.perform() dans GoToAdminPage.setUp() , et cela réaliserait techniquement ce que je veux faire. Cependant, ce n'est pas le cas et a le même effet que je l'ai mentionné ci-dessus.

En regardant en ligne, j'ai vu que je pouvais aussi faire en sorte que GoToAdminPage extends Login , mais cela a également le même résultat.

Enfin, j'ai tenté de placer l'ensemble du processus Login.test() dans une fonction distincte de la classe Login que je pourrais appeler dans GoToAdminPage , mais cela a le même résultat.

En résumé, ce qui semble se produire est que, lorsque j'appelle un autre test JUnit dans GoToLoginPage , il effectue le test, mais le fait comme un test séparé .

Ce que je veux, c'est pouvoir faire un gros test, où, une fois que j'ai appelé Login , je peux interagir avec la page post-login avec mon utilisateur connecté. Essentiellement, je veux juste que GoToAdminPage soit une extension Processus de Login .

Est-ce possible?

Voici mon code actuel:

Login.java

public class GoToAdminPage extends BasicTest {

    Login Login = new Login();
    /**
     * @throws java.lang.Exception
     */
    @Before
    public void setUp() throws Exception {
        super.setUp();
        Login.login(driver);
    }

    /**
     * @throws java.lang.Exception
     */
    @After
    public void tearDown() throws Exception {
        super.tearDown();
    }

    @Test
    public void test() throws Exception {
        ...post login test process...
    }
}

GoToAdminPage.java

public class Login extends BasicTest {

    /**
     * @throws java.lang.Exception
     */
    @Before
    public void setUp() throws Exception {
        super.setUp();
        driver.get(constants.connectionUrl);
    }

    /**
     * @throws java.lang.Exception
     */
    @After
    public void tearDown() throws Exception {
        super.tearDown();
    }

    @Test
    public void test() throws Exception {
        this.login(driver);
    }

    public void login(WebDriver d) throws InterruptedException {
        ...login process using webdriver....
    }
}

Pourtant, cela a l'effet susmentionné.


0 commentaires

3 Réponses :


0
votes

Définissez les étapes de «connexion» comme une méthode régulière (non annotée avec @Test ). Ensuite, vous pouvez appeler cette méthode où que vous soyez. À partir de votre méthode de test de connexion (en ajoutant les assertions requises après que les étapes ont été effectuées) et à partir de toute méthode de setUp sans exécuter réellement le test de connexion.


1 commentaires

C'est essentiellement ce que j'ai fait. J'ai défini un login() méthode dans mon Login classe, que j'appelle dans mon @Test méthode Login - @Before GoToAdminPage Login , et dans ma @Before méthode GoToAdminPage . Je vais mettre le code dans l'OP.



0
votes

Vous devez appliquer le modèle d' objet de page et créer une page d'objet de connexion.

L'un des modèles les plus courants de l'automatisation Web est le modèle d'objet de page. Pour comprendre l'objectif principal du modèle, vous devez d'abord réfléchir à ce que font vos tests d'automatisation Web. Ils naviguent vers différentes pages Web et cliquent / tapent sur / dans divers éléments. Le modèle d'objet de page enveloppe tous les éléments, actions et validations se produisant sur une page dans un seul objet - Objet de page. la source

Certains des avantages du modèle d'objet de page énumérés ci-dessous,

  • Réduit la duplication du code
  • Rend les tests plus lisibles et plus robustes
  • Améliore la maintenabilité des tests

IMHO créer des dépendances entre les cas de test n'est pas une bonne pratique.

Exemple:

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.FindBy;
import org.openqa.selenium.support.PageFactory;

public final class LoginPage {

    @FindBy(id="username")
    private WebElement username;

    @FindBy(id="password")
    private WebElement password;

    @FindBy(id="loginBtn")
    private WebElement submit;

    public LoginPage(WebDriver driver) {
        PageFactory.initElements(driver, this);
    }

    public void submit(String username, String password) {
        this.username.sendKeys(username);
        this.password.sendKeys(password);
        submit.click();
    }
}


1 commentaires

Malheureusement, je travaille sur un projet où les pages sont constituées d'éléments dynamiques, et aucune page n'est garantie d'exister à l'exception des pages de connexion. Donc mes tests doivent être écrits module par module. Pourtant, je peux adapter le POP pour travailler avec des modules au lieu de pages. C'est essentiellement ce que je fais. Bon nombre des pratiques recommandées - généralisation et factorisation pour empêcher la répétition du code et augmenter le nombre de tests génériques - j'avais l'intention d'utiliser et j'utiliserai. Merci pour l'annotation FindBy , sera très utile.



0
votes

Au final j'ai trouvé la solution:

  • GoToAdminPage étend la Login

  • GoToAdminPage.setUp() appelle parent.setUp()

  • GoToAdminPage.test() appelle parent.test()

En utilisant cela, j'ai pu faire en sorte que mon deuxième test utilise son parent comme phase de configuration.


0 commentaires