Temat: rozwój aplikacji pod testy automatyczne

Hejże.

Załóżmy, że przeszliśmy już temat "czy warto automatyzować", jesteśmy świadomi "za i przeciw", przystępujemy do zastanawiania się jak się za to zabrać.

Moje pytanie jest następujące: czy dostawca może ułatwić w jakiś sposób późniejszą automatyzację testów? Tzn. czy może ją rozwijać w taki sposób, żeby nie tworzyć dodatkowego kodu (np. wysyłającego gdzieś sygnały/statusy) ale mimo wszystko ułatwić - albo chociaż nie utrudniać - automatyzację?

Mówimy tu o aplikacjach ogólnie - od html/ajax/css po aplikacje flexowe (odpalane również w środowisku Adobe AIR).

Do rozważenia dwa przypadki:

- aplikacja już istniejąca
- całkowicie nowa aplikacja

Może macie jakieś przemyślenia na ten temat?

Pozdr,
DP.

Temat: rozwój aplikacji pod testy automatyczne

Jeśli dostawca stosował TDD, to z założenia aplikacja powinna być testowalna by default. I w tym przypadku nie potrzeba dedykowanego kodu dla testowania aplikacji.

Podnieść testowalność istniejącej aplikacji bez dodatkowego kodowania - ja tego nie widze.

Jeśli masz interface w xhtml/HTML to trzeba zwrócić uwagę na webdesignerów, UCD, czy jak tak się nazwą (wiadomo o co chcodzi ;)), żeby w kodzie umieszczali odpowiednie nazwy dla reprezentowanych danych, formularzy i id dla <div>, wtedy pisanie skryptów automatyczny przy użyciu XPath jest dużo latwiejsze, a dla nich nie oznacza to dodatkowej pracy.

I to by były moje przemyślenia na obecną chwilę ;)

Pozdr.

Temat: rozwój aplikacji pod testy automatyczne

TDD raczej niewiele wnosi od strony zespołu testów - to po prostu agile'owy sposób wytwarzania oprogramowania, w którym najpierw powstają testy z użyciem na przykład mocków do interfejsów tylko po to, żeby je można była najpierw zfailować a potem oprogramować komponenty tak, żeby przechodziło. Zdecydowanie bliżej warstwy projektowej systemu niż wymagań, które są podstawą do testów funkcjonalnych / systemowych.

Ułatwianie testowania istniejącego oprogramowania - wydaje mi się, że niezależnie od tego jak / co automatyzujemy, zależy od zakresu zmian, które mogą zostać wprowadzone.

Ułatwianie testowania nowego oprogramowania - jak najbardziej, jeżeli chodzi o GUI / frontend to:

Web-based - tutaj i tak jest łatwo bo markup HTML da się parsować na lewo i prawo. Gorzej, jak developerzy przesadzą z ilością client-script'u i powrzucają trochę embedded objects... Na początek proponuję Web Accessibility initiative.

Java Swing / AWT - zasadniczo http://java.sun.com/javase/technologies/accessibility/... i jesteśmy ustawieni. Java Access Bridge nawet nie jest wymagany jak korzysta się z maszyny 1.6 - jest odpowiednie API, nawet wystawia eventy do nagrywania :) Tak czy inaczej - customowe kontrolki mają mieć poimplementowane interfejsy Accessible. Jeżeli developerzy nie pomyśleli w ogóle o Accessibility, nie mamy JAB ani nic innego do pomocy, to zawsze można zaprzędz do roboty JNI i postawić własną maszynę Javy - to dla ambitnych.

Windows-based -
a) Kod niezarządzany (C++/MFC albo VB6) - IAccessibility. Jak go nie ma to pozostają zwykłe Windowsowe kontrolki - działa dopóki ktoś nie wrzuca jakiś śmiesznych datagridów itp...

b) Kod zarządzany (.NET / Silverlight) - nic prostszego. Managed Spy i gotowe. Aczkolwiek znowu uczulałbym developerów na IAccessible, dobrą praktyką jest to implementować, można wtedy używać nawet toporne toole do autmatyzacji, byle potrafiły wysyłac do aplikacji key stroke'y.

JVM by Microsoft - podobno jest jeszcze używane. Tutaj znowu kontrolki są zwykłymi Windowsowymi komponentami więc mamy takie możliwości jakie one nam je dają. Jerze developerzy wrzucają swoje - niech implementują IAccessible.

Flex - Adobe też zrobiło postępy, osobiście się tym nie bawiłem to nie doradzę...

Z tego co widać wszystko powyższe ma jedną cechę wspólną, która nazywa się Accessibility. Jak możecie lobbować za tym, żeby było to implementowane to walczcie do końca - opłaci się w przyszłości.

Temat: rozwój aplikacji pod testy automatyczne

Krzysztof Mierzejewski:

Cześć Krzysztof, dzięki za wyczerpującą odpowiedź! :)

Flex - Adobe też zrobiło postępy, osobiście się tym nie bawiłem to nie doradzę...

A ten temat w zasadzie mnie najbardziej interesuje (poza zabawami z kodem zarządzanym i niezarządzanym).

Pozdr,
DP.

Temat: rozwój aplikacji pod testy automatyczne

Krzysztof Mierzejewski:
TDD raczej niewiele wnosi od strony zespołu testów - to po prostu agile'owy sposób wytwarzania oprogramowania, w którym najpierw powstają testy z użyciem na przykład mocków do interfejsów tylko po to, żeby je można była najpierw zfailować a potem oprogramować komponenty tak, żeby przechodziło. Zdecydowanie bliżej warstwy projektowej systemu niż wymagań, które są podstawą do testów funkcjonalnych / systemowych.

No i tu się nie zgodzę. TDD poza tym co napisałeś zmusza developerów do innego podejścia. Muszą pisać kod tak, żeby umożliwić jego testowanie. I właśnie ten aspekt jest tutaj bardzo ważny. TDD automatycznie wpływa też na wybór technologi a dokładniej frameworku, który ma zintegrowany mechanizm testów dla MVC.

Kolejna bardzo ważna cecha TDD - każdy requirement musi być zmapowany w testach i każda zmiana wymagań spowoduje natychmiastowy fail w testach. Czyli z jednej strony mamy automatyczną dokumentacje wymagań, z drugiej nie da się niepostrzeżenie dokonać zmiany w systemie. I dlaczego TDD ma się ograniczać tylko do Unit Testing? Można zrobić cały End-To-End testing, czy też testy interfaców z systemami zewnętrznymi w dowolnej konfiguracji. I wystarczy wyobrazić sobie sytuację, gdy podłączamy aplikację do rzeczywistych systemów zewnętrznych np. biling i IN, odpalamy testy i mamy odpowiedz na pytanie "Czy konfiguracja jest poprawna?".
Gotowy produkt będzie wyposażony w interface'y umożliwiające przetestowanie całej funkcjonalności. To chyba jest bardzo duże ułatwienie dla testów automatycznych, prawda?

Temat: rozwój aplikacji pod testy automatyczne

TDD zazwyczaj związane jest z najniższą warstwą abstrakcji - metodami. Unit testy piszemy dla dobrze wyizolowanych funkcjonalności i wykrywamy błędy w ich zachowaniu, jak również
wszelkie niskopoziomowe bugi, jak null pointery, wycieki pamięci,
etc. Niemniej jednak wpływ stosowania TDD w projekcie sięga wysoko.
Pierwsza sprawa:
Komponenty rozwijane przez TDD mają zwykle dużo lżejsze powiązania między sobą (coupling), co znacznie upraszcza testy integracyjne.
Druga sprawa:
To, co pisał Krystian, można stosować podobną metodykę do TDD na wyższych poziomach abstrakcji od integracji po testy funkcjonalne włącznie.

Co do pracy z istniejącym kodem, polecam książkę: http://www.amazon.com/Working-Effectively-Legacy-Rober...

PozdrawiamJulian Warszawski edytował(a) ten post dnia 21.05.09 o godzinie 13:40