Quantcast
Channel: blog.testowka.pl » Kurs Selenium
Viewing all articles
Browse latest Browse all 8

Kurs Selenium część 6 – parametryzacja testów

$
0
0

W poprzedniej części kursu testowaliśmy formularz logowania. Przetestowaliśmy jedynie pozytywny scenariusz a co z negatywnymi – co z walidacją?
Pierwszy pomysł jaki się nasuwa to, że trzeba skopiować powyższy test i zmieniać w kopiach dane wejściowe. Niestety tworzymy w ten sposób wiele duplikacji, które utrudnią dalsze utrzymywanie testów – co na przykład jeśli zmieni się formularz logowania, albo w ogóle sposób logowania?

Jest lepsze – bardziej generyczne rozwiązanie.

Wystarczy naszym testom nadać parametry – użyjemy w tym celo adnotacji @DataProvider.

Najpierw potrzebujemy wprowadzić drobne zmiany w naszej metodzie logIn() tak by przyjmowała parametry:

private void logIn(String login, String password) {
	WebElement loginField = driver.findElement(By.id("login"));
	WebElement passwordField = driver.findElement(By.id("password"));
	WebElement commit = driver.findElement(By.name("commit"));

	loginField.sendKeys(login);
	passwordField.sendKeys(password);
	commit.click();
}

Zalecam przeciążenie tej metody – czyli utworzenie dwóch metod logIn() oraz logIn(String login, String password) – dzięki takiemu podejściu nasz poprzedni test nadal będzie działał ale co najważniejsze metoda logIn() bez parametrów będzie mogła być użyta w wielu testach bez obaw o ewentualne zmiany. Przykładowo gdybyśmy zawsze używali w każdym teście logIn(“admin”, “password”) i nagle z jakiś powodów – np. polityki dotyczącej haseł, zmienia się hasło w naszych danych testowych, albo w ogóle nie logujemy się już przy użyciu hasła tylko np. przez facebooka. W takiej sytuacji dzięki przeciążonej metodzie logIn() możemy zmienić sposób logowania tylko w jednym miejscu i wszystko nadal będzie działać.

private void logIn() {
	logIn("admin", "password");
}

Dobrze, skoro mamy już metodę służącą do logowania i przyjmującą parametry to teraz należy przygotować nasz test tak by parametry przyjmował.

Robi się to w następujący sposób. W adnotacji @Test przekazujemy dataProvider – wskazujemy nazwę providera. Poniżej definiujemy wspomniany provider przy użyciu adnotacji @DataProvider.

W metodzie testu przekazujemy parametry shouldNotBePossibleToLogInWithIncorrectCredentials(String login, String password)

import org.testng.annotations.DataProvider;

@Test(dataProvider = "wrongLoginCredentials")
public void shouldNotBePossibleToLogInWithIncorrectCredentials(
	String login, String password) {
	// GIVEN
	openLoginPage();
	// WHEN
	logIn(login, password);
	// THEN
	checkIfLogedIn();
}

@DataProvider
public Object[][] wrongLoginCredentials() {
	return new Object[][] { { "admi", "password" }, { "admin", "passwor" },
			{ "admi", "passwor" }, { "admi", "" }, { "", "password" }, { "", "" }, };
}

Zastosowań @DataProvider może być wiele – odsyłam do dokumentacji.


Viewing all articles
Browse latest Browse all 8

Trending Articles


TRX Antek AVT - 2310 ver 2,0


Автовишка HAULOTTE HA 16 SPX


POTANIACZ


Zrób Sam - rocznik 1985 [PDF] [PL]


Maxgear opinie


BMW E61 2.5d błąd 43E2 - klapa gasząca a DPF


Eveline ➤ Matowe pomadki Velvet Matt Lipstick 500, 506, 5007


Auta / Cars (2006) PLDUB.BRRip.480p.XviD.AC3-LTN / DUBBING PL


Peugeot 508 problem z elektroniką


AŚ Jelenia Góra