8

Biorąc pod uwagę prostą stronę: pojawia Please enter an email address wiadomośćSprawdź, czy pojawia się komunikat „Proszę podać adres e-mail”

<form> 
    <input type="email"> 
    <button>click</button> 
</form> 

Gdybym wprowadzić coś w polu tekstowym, które nie jest E-mail i kliknij przycisk.

Czy istnieje sposób sprawdzenia, czy wiadomość pojawia się przy użyciu Selenium lub Watir? O ile widzę, nic nowego nie pojawia się w DOM przeglądarki.

Ponieważ strona korzysta z funkcji sprawdzania poczty e-mail wbudowanej w przeglądarkę, czy ma sens sprawdzanie, czy wyświetlany jest komunikat o błędzie? Jest na tym samym poziomie co sprawdzenie, czy pasek przewijania przeglądarki działa. Nie sprawdzamy już aplikacji internetowej, ale platformy (przeglądarki).

Wcześniejsze powiązane pytanie tutaj na SO jest: How do I test error conditions in HTML5 pages with cucumber?

+0

Czy ostrzeżenie pojawia się na stronie? Moim pierwszym przypuszczeniem byłoby pobranie identyfikatora przez firebug, a następnie użycie go później na –

+2

Ostrzeżenie pojawia się na stronie - widzisz je w oknie przeglądarki, ale nie pojawia się ono na stronie - nic nowego nie pojawia się w DOM. Magia. :) –

+3

Myślę, że to nie ma sensu, ponieważ oznacza to testowanie strony trzeciej, a nie aplikacji internetowej. – p0deje

Odpowiedz

4

Zgodziłbym się, że zaczyna to zbliż się do "testowania przeglądarki", otoh jeśli twój kod zależy od tej funkcji przeglądarki, to strona musi wygenerować poprawny kod html (5), aby przeglądarka wiedziała, że ​​chcesz tego poziomu weryfikacji, i to jest coś, co możesz uprawomocnić.

Niektóre dobre tło na ten temat w art of the web

Walidacja boczny przeglądarka jest wyzwalane przez połączenie typu specyficzne wejściowego (co można sprawdzić poprzez .type metody Watir) jak i nowej required atrybutu (który może być tricker do sprawdź) Biorąc to pod uwagę, myślę, że widzę tutaj całkiem niezłą przyczynę nowej funkcji w Watir. Myślę, że moglibyśmy użyć metody .required?, która powinna być obsługiwana dla wszystkich elementów wejściowych, które obsługują nowy "wymagany" atrybut, i zwróciłaby wartość true, gdyby ten "wymagany" atrybut był obecny.

W tej chwili możesz zrobić, jeśli wiesz, że korzystasz z przeglądarki HTML5 obsługującej tę funkcję, możesz sprawdzić, czy typem wejściowym jest "e-mail", a także czy jest tam atrybut "wymagany" . (Nie mam pomysłu, jak to zrobić, ale może ktoś inny może zasugerować jakiś sposób).

Inną rzeczą, na którą należy polegać, jest podanie nieprawidłowej wartości i upewnienie się, że formularz nie pozwoli na przesłanie formularza. na przykład to wymóg walidacji lub jedynie doradztwo. (i nie zapomnij sprawdzić strony serwera, przesyłając nieprawidłowe dane w każdym razie używając czegoś takiego jak curl lub httparty, ponieważ wrogi użytkownik może z łatwością ominąć każdą walidację weryfikatora i przesłać tę formę z fałszywymi lub nawet "wrogimi" wartościami mającymi na celu wywołanie bufora atak polegający na przepełnieniu lub wstrzyknięciu Żadna strona nie powinna zależeć wyłącznie od walidacji po stronie klienta.)

Inną kwestią, którą należy wziąć pod uwagę, jest to, co dzieje się wtedy, gdy użytkownik znajduje się w przeglądarce, która NIE obsługuje tej konkretnej funkcji sprawdzania oryginalności. Zakładam, że javascript po stronie klienta i komunikat, który jest wyświetlany.

W takim przypadku to naprawdę zależy od sposobu, w jaki wiadomość jest "wyświetlana". W testowanej aplikacji wiadomości tego typu znajdują się w poręcznych elementach div z unikalnymi klasami, które są kontrolowane przez css, aby normalnie były ukryte, a następnie ustawiane na wyświetlanie, gdy po stronie klienta JS wykryje potrzebę wyświetlenia komunikatu dla użytkownik. Więc oczywiście mam testy na takie rzeczy. Oto przykład jednego dla kogoś, kto zgadza się na nasze warunki. (Uwaga: używamy ogórek, a gem Test-Fabryka zrobić przedmiotów stron i obiektów danych)

zacznijmy z komunikatem, a co prawym click.examine-element objawia

The message as it appears on our registration page

scenariusz na plik grower_selfregister.feature wygląda to

Scenario: self registering grower is required to agree to terms and conditions 
    Given I am a unregistered grower visiting www.climate.com 
    When I try to self-register without agreeing to the terms and conditions 
    Then I am informed that Acceptance of the terms and conditions is required 
    And I remain on the register page 

krytyczne etapy ogórka są:

When /^I try to self-register without agreeing to the terms and conditions$/ do 
    @my_user.self_register(:agree_to_terms => FALSE) 
end 

Then /^I am informed that Acceptance of the terms and conditions is required$/ do 
    on Register do |page| 
    page.agree_to_terms_required_message.should be_visible 
    end 
end 

Then /^I remain on the register page$/ do 
  on Register do |page| 
    #ToDo change this to checking the page title (or have the page object do it) once we get titles 
    page.url.should == "#{$test_site}/preso/register.html" 
  end 
end 

Odpowiednie fragmenty obiektu register.rb stronie są

class Register < BasePage 

    #bunch of other element definitions removed for brevity 

    element(:agree_to_terms_required_message) {|b|b.div(:class => "terms-error")} 

end 

Czy to pomoże podać przykład?

Uwaga: można z łatwością stwierdzić, że druga walidacja (pozostanie na stronie) jest zbyteczna, ponieważ nie zobaczę tej wiadomości, jeśli nie znajduję się jeszcze na stronie. Dodaje jednak klarowności do oczekiwanego doświadczenia użytkownika opisanego w scenariuszu. Ponadto może być bardzo ważne, jeśli implementacja, w której należy dokonać zmiany, na przykład, jeśli zdecydowano się użyć czegoś takiego jak alert javascript, może być ważne, aby sprawdzić, czy raz usunięty (coś, co prawdopodobnie zrobiłby krok "Widzę komunikat"), mimo to użytkownik nie wszedł na stronę.

4

Można spróbować jak to

JavascriptExecutor js = (JavascriptExecutor) driver; 
driver.findElement(By.cssSelector("input[type='email']")).sendKeys("asd"); 
Object s=js.executeScript("return document.getElementById(\"a\").validity.valid"); 
System.out.println(s); 
driver.findElement(By.cssSelector("input[type='email']")).sendKeys("[email protected]"); 
s=js.executeScript("return document.getElementById(\"a\").validity.valid"); 
System.out.println(s); 

wyjście do powyższej linii jest

false 
true 

Więc na tej podstawie można stwierdzić, że czy podana wartość jest ważna, czy nie.

Poniżej javascript logika zwróci true/false na podstawie ważności dziedzinie

document.getElementById(\"a\").validity.valid 

PS: zakładam tag wejściowy ma id "a"

2

Nie znalazłem sposobu sprawdzenia rzeczywistego komunikatu o błędzie. Można jednak sprawdzić, czy pole wejściowe jest niepoprawne po wprowadzeniu adresu bez wiadomości e-mail przy użyciu pseudo-selektora CSS :invalid.

WebElement invalidInput = driver.findElement(By.cssSelector("input:invalid")); 
assertThat(invalidInput.isDisplayed(), is(true)); 
+0

to rozwiązanie działa na selen – e4c5