Avant c'est tout
Salut Je m'appelle Dima et je ne connais pas les schémas. Quant au testeur, pour ne pas dire qu'il est problématique. Comment pour un automate ..? Eh bien, soyons honnêtes, vous pouvez aussi vivre.
Des clavardages, des conférences et de la communication avec des collègues, c'est clair: le modèle principal - PageObject - est appris, que faut-il d'autre?
Et voici un grand paragraphe de réflexion sur les raisons pour lesquelles nous n'utilisons pas vraiment les modèles de conception: ne les connaissons-nous pas, ou est-ce bien sans eux? Il y a également eu des approfondissements dans l'histoire selon lesquels les modèles ne sont pas pour vous, mais pendant des décennies, des connaissances et des techniques éprouvées, des arguments pour et la mention de camarades bien connus qui sont contre.
Mais, en fin de compte, connaître les schémas ne fera certainement pas de mal.
Donc, en aucun cas vous incitant à tordre les modèles partout dans le code, je commence à publier une série d'articles sur les modèles.
Un peu plus sur le format et c'est parti
Les articles / livres / cours vidéo sur les modèles eux-mêmes sont assez décents. Et je suis sûr que vous pouvez facilement trouver une ressource avec une explication compétente, des exemples sur votre PJ préféré, des e-mails, etc.
La tâche de cet article et des suivants est de parler des modèles à ceux qui travaillent déjà avec le code, mais qui n'ont pas une bonne base théorique. Donc, ces articles sont peut-être pour moi en premier lieu.
Eh bien, puisque je suis moi-même un testeur, et même dans mon cercle d'amis, il y en a beaucoup des mêmes, les histoires seront inclinées vers l'automatisation des tests.
Certains motifs semblent étranges et peu utiles. Et avec certains, au contraire, vous constaterez que vous avez mis en œuvre quelque chose comme ça depuis longtemps, vous ne saviez tout simplement pas que cela s'appelait ainsi.
En tout cas, j'espère que vous trouverez quelque chose d'utile pour vous.
Et oui, je serai très heureux des critiques constructives dans les commentaires.
Ici.
- pour moi - dit
- ce qui sera - dit
- pourquoi - dit
- pour qui et comment - dit
Vous pouvez commencer.
Mandataire - Mandataire - Adjoint
Théorie (un peu)
Modèle de proxy (dans les éditions russes,
adjoint ). L'idée est de donner au travail non pas un véritable objet, mais une substitution qui utilise les méthodes de l'objet + notre logique, si nous en avons ajouté un. C’est tout.
Comment faire:
1. Créez une interface avec les méthodes publiques de l'objet que nous voulons remplacer
2. Créez une classe qui
- implémente cette interface
- a accès à l'objet d'origine pour appeler ses méthodes
3. Ajoutez votre logique aux méthodes de la classe créée
Pratique
En pratique, cela devrait ĂŞtre plus clair.
Dano: Nous avons un WebDriver. Et il a une méthode findElements (By by);
Tâche: J'ai vraiment besoin de consigner le nombre d'éléments trouvés par le sélecteur.
Chaque fois que j'appelle une méthode
driver.findElements(By.cssSelector(".item"));
Je veux voir un enregistrement dans les journaux - combien d'éléments ont été trouvés
Solution 1. Sur le front. Qu'est-ce qu'il y a: je l'ai utilisé.
Nous le prenons simplement et, à chaque appel, écrivons combien ont été trouvés:
List<WebElement> items = driver.findElements(By.cssSelector(".item")); logger.info("Found {} items", items.size());
L'option est normale, alors que de tels appels sont, disons, 7. Bien que les inconvénients de cette approche soient déjà évidents pour quiconque a au moins une fois «légèrement modifié son code».
Solution 2. Nous utilisons un proxy.
WebDriver est une interface. Méthodes déclarées, mais pas d'implémentation. Les implémentations incluent ChromeWebDriver, FirefoxWebDriver, etc.
Nous, dans les tests, n'avons pas à travailler avec une classe particulière pour Chrome ou Safari. Il suffit que la classe implémente l'interface WebDriver. Nous allons le faire:
Nous créons une interface avec les méthodes publiques de l'objet que nous voulons remplacer
Dans notre exemple, une telle interface existe déjà - WebDriver.
Créez une classe qui
- implémente cette interface
- a accès à l'objet d'origine pour appeler ses méthodes
public class LoggerWebDriver implements WebDriver{ private WebDriver driver; public void get(String s) { } public List<WebElement> findElements(By by) { return null; } public WebElement findElement(By by) { return null; }
Ajoutez votre logique aux méthodes de la classe créée
public class LoggerWebDriver implements WebDriver { private WebDriver driver; private final Logger logger = LogManager.getLogger(LoggerWebDriver.class); LoggerWebDriver() {
Qu'est-il arrivé?Ajouté à la classe
private WebDriver driver;
C'est le même objet que nous voulons remplacer. Ce sont ses méthodes que nous appellerons plus loin.
Maintenant, vous pouvez regarder, par exemple, la méthode
public void get(String var1) { driver.get(var1); }
La méthode ne fait qu'appeler get () sur le pilote réel.
Et voici la méthode
public List<WebElement> findElements(By var1) { List<WebElement> items = driver.findElements(var1); logger.info("Selector {}. Found {} elements", var1.toString(), items.size()); return items; }
Nous nous sommes développés selon notre tâche.
C'est tout ce que vous pouvez utiliser dans les tests:
WebDriver driver = new LoggerWebDriver(); driver.get("http://google.com"); List<WebElement> items = driver.findElements(By.cssSelector("a"));
Ici. Le modèle est bon si vous devez raccrocher la journalisation, la mise en cache, l'initialisation paresseuse, le contrôle d'accès aux méthodes. En général, si vous écrivez du code et que vous voulez vraiment avoir une sorte d'intercalaire avec vos fonctionnalités, l'une des options est un proxy.
Maintenant que nous connaissons un autre motif, permettez-moi de vous rappeler que lorsqu'un marteau est dans votre main, tout autour de nous semble ĂŞtre des clous. Gardez cela Ă l'esprit.