… a koniec średnio radosny.

Na początek będzie trochę o zestawianiu środowiska, czyli o rzeczach, które trzeba niestety zrobić i nie są one zbyt przyjemne dla naszej psychiki.

W moim przypadku mam za zadanie przygotować lekki i wygodny framework do testowania naszych aplikacji webowych. Ogólne założenia:

  • Pozwala na testowanie wszystkich (naszych) aplikacji.
  • Pozwala na pisanie testów z zachowaniem języka domeny.
  • Jest stosunkowo nieskomplikowany i łatwy w użyciu.

Ostatni punkt jest umowny o oznacza mniej więcej tyle, że API nie powinno mieć więcej niż kilka klas i odpowiadać mniej więcej elementom wizualnym w UI aplikacji oraz mapować akcje użytkownika na jakieś metody czy obiekty.

Kolejna rzecz to ten nieszczęsny „język domeny”, który w tym przypadku oznacza mniej więcej tyle co:
Dla obiektów:

  • Aplikacja dzieli się na ekrany.
  • Ekran jest formularzem albo listą.
  • Formularz zawiera pola.
  • Lista zawiera rekordy.

Dla akcji:

  • Do aplikacji można się zalogować i wylogować.
  • Ekran można otworzyć lub wysłać.
  • Pole można odczytać i można w nim pisać.
  • Listę można odczytać.

Czyli jest nieźle. Można sobie na tej podstawie wybudować jakieś ogólne wyobrażenie tego co będzie zawierać ta maszynka.

Czas na naszą narzędziownię. Będzie ona oparta o gotowe rozwiązania wspierające tworzenie testów aplikacji webowych. Zatem na pokładzie witamy:

  • Selenium – framework testów webowych.
  • Selenium IDE for FireFox – plugin do FF.
  • Firebug – kolejny plugin do FF ułatwia pracę z kodem HTML i ma m.n. obsługę xPath.
  • TestNG – silnik testów w javie, będzie nam to wszystko zbierał do kupy.
  • Scala – język w jakim to wszystko napiszemy.
  • Eclipse Indigo – nasze IDE.
  • Maven – budowanie, zarządzanie, wkurwianie to jego domena

Tu dochodzimy do głównej części dzisiejszego wpisu, czyli jak spiąć Eclipse ze Scalą (i Selenium). O ile integracja z Selenium polega w tym przypadku na podpięciu w pom.xml:

Listing 1. zależności od Selenium

<dependency><groupid>org.seleniumhq.selenium</groupid><artifactid>selenium</artifactid><version>LATEST</version><type>pom</type></dependency>

i cierpliwym poczekaniu, aż wszystko się ściągnie to ze Scalą jest kilka wrzodów.

Scala IDE

Bardzo fajne rozwiązanie dla programistów pracujących w Eclipse, którzy chcą używać Scali. Tyle tylko, że w wersji stabilnej z obsługą Scali 2.8.0 jest moim skromnym zdaniem kompletnie nieprzydatne. Wynika to z dwóch rzeczy. Po pierwsze sam kompilator Scali wymaga dość dużo RAMu i Eclipse musi mieć w opcjach wpisane co najmniej 1024m. Trzeba pogrzebać w eclipse.ini i poustawiać -Xmx oraz -Xms. Po drugie plugin wykorzystuje swój weavering, który ma tendencję deadlocków. Rozwiązaniem jest znowuż edycja ecclipse.ini:

Listing 2. workaround do deadlocków Scala IDE

 -XX:+UnlockDiagnosticVMOptions
 -XX:+UnsyncloadClass
 -Dosgi.classloader.lock=classname

tyle tylko, że jest to rozwiązanie klasy „będzie się cięło rzadziej, ale będzie”.
Rozwiązaniem pierwszego problemu jest za to wykorzystanie Scali 2.9.0RC2 i odpowiedniej wersji IDE, czyli bety 2.0.0. W celu oszczędzenia sobie ciężkiego urazu psychicznego polecam w tym przypadku instalację manualną przez rozpakowanie paczki z pluginem do dropins i olanie update site. W razie czego można się łatwo wrzodu pozbyć.

Na koniec konfiguracja pluginu scali do mavena, który pozwala na uniknięcie instalacji Scali w systemie (czasami przydatne):

Listing 3. Konfiguracja pom.xml


<plugin><groupid>org.scala-tools</groupid><artifactid>maven-scala-plugin</artifactid><version>LATEST</version><executions><execution><goals><goal>compile</goal><goal>testCompile</goal></goals></execution></executions><configuration><scalaversion>${scala.version}</scalaversion></configuration></plugin><dependency><groupid>org.scala-lang</groupid><artifactid>scala-library</artifactid><version>${scala.version}</version></dependency><dependency><groupid>org.scalatest</groupid><artifactid>scalatest</artifactid><version>1.3</version></dependency>

Tu mała uwaga na temat Eclipse. Pytanie jeżeli w projekcie definiujemy scala.version i mamy je też skonfigurowane w settings.xml, to które zostanie wykorzystane? Zdrowy rozsądek podpowiada, że to z pom.xml jak to ma miejsce w przypadku chociażby pluginów. No niestety zdrowy rozsądek należy odłożyć i dzięki temu odkrywamy, że zmienne w pom.xml są nadpisywane przez te z settings.xml.
Mam tu jeszcze Scala Test, czyli takiego DSLa do testów. Przyda się.