2013-03-19 29 views
5

Wyobraź sobie, że masz dość złożoną architekturę zorientowaną na usługi, wykonaną z różnych komponentów. Komponenty są napisane w różnych językach (Java, PHP, Ruby) i komunikują się ze sobą na różne sposoby (np. Interfejs użytkownika, interfejs API REST, w niektórych przypadkach współdzielenie niektórych tabel DB itp.).Wielojęzyczne środowisko testowania integracji

Próbuję zaprojektować strukturę testowania integracji dla niektórych testów end-to-end. Mamy już testy jednostkowe/integracyjne dla pojedynczych komponentów, ale chcielibyśmy zbudować coś, co w pełni przetestuje nasz wdrożony system (w rzeczywistym środowisku) od końca do końca, aby upewnić się, że funkcjonalności (pod względem oczekiwanych zachowań poszczególne komponenty) są dostarczane poprawnie, a architektura jest poprawnie skonfigurowana.

Pierwszymi problemami, z jakimi mam do czynienia, jest to, że większość naszego interfejsu jest napisana w PHP, a testy integracji interfejsu użytkownika są już dla niego napisane za pomocą Cucumber i kilku wtyczek na wierzchu. Konstrukcja testowa, którą piszę (w języku Java), powinna uruchomić te testy funkcji, a następnie sprawdzić, czy zachowanie powiązanych komponentów jest zgodne z oczekiwaniami.

Oczywiście mogłem przepisać testy interfejsu użytkownika przy użyciu komponentu przyjaznego dla środowiska Java, takiego jak Selenium, ale nie ma sensu powielać tego wysiłku.

Innym rozwiązaniem jest uruchomienie istniejących testów za pomocą wywołania exec() w Javie, poczekać na ich powrót, ewentualnie przeanalizować dane wyjściowe i wykonać inne czynności/kontrole, które należy wykonać.

Osadzanie istniejącego kodu PHP w Javie nie wydaje się dobrym rozwiązaniem, biorąc pod uwagę sposób, w jaki zostały napisane projekty.

Żadne z opisanych rozwiązań nie wydaje mi się przekonujące. Idealnie byłoby mieć coś w rodzaju wielojęzycznego (i wielogumowego) środowiska integracyjnego, które można podłączyć w ramach tych samych testów zestawów testów napisanych w różnych językach i dla różnych środowisk/komponentów.

Czy ktoś zna jakieś narzędzie lub ramy, które zmierzają w tym kierunku? Jeśli nie, jakie może być dobre podejście do tego rodzaju problemów?

Odpowiedz

0

Czy rozważałeś testowanie pełnego stosu z czymś takim jak Jmeter?

Można zbudowany testy, które działają przeciw pełni wdrożonego oprogramowania

  • utworzyć użytkownika
  • potwierdzają, że użytkownik powodzeniem tworzyć screeen pokazano
  • potwierdzają, że użytkownik znajduje się w bazie danych zgodnie z oczekiwaniami
  • usuwać użytkownik
  • potwierdź, że użytkownik został usunięty

W ten sposób testujesz swój interfejs użytkownika, logikę biznesową i magazyn danych jednocześnie. Może być również używany do testowania obciążenia.

Jmeter

+0

Dzięki za pomysł, ale byłoby przyjęcie JMeter (z punktu przerwania wsparcie!) oznacza przepisywanie istniejących testów od zera. JMeter nie interpretuje również kodu Javascript, co stwarza duże ograniczenie w testowaniu interfejsu użytkownika. – kappolo

+0

Jestem nieco zdezorientowany, jak sądzę, chcesz zbudować strukturę zestawu testów, która wywołuje twoje istniejące testy jednostkowe? Czy to zapewni ci informacje wykraczające poza twoje dotychczasowe testy? – mconlin

+0

Przepraszam, jeśli nie byłam jasna. Ponieważ chcę utworzyć pełny test integracyjny (tj. Integrujący wszystkie komponenty mojego systemu), chcę ponownie wykorzystać część istniejących już testów integracyjnych i połączyć/zintegrować je z nowymi testami. – kappolo

1

Nie wiem, czy to pomoże, ale może spojrzeć na https://github.com/nablex/glue. Jest to język skryptowy, który opracowałem z naciskiem na testowanie (integracyjne).

Obsługuje skrypty selenowe po zainstalowaniu, jeśli podłączysz https://github.com/nablex/glue-selenese i jest rozszerzalny o bardzo.

obecnie używam go na klienta z niektórych niestandardowych rozszerzeń do uruchomienia starszych skryptów napisanych w Fox PRO (I rzeczywiście przepisany fox metod pro ... dreszcz) oraz trybu legacy więc są one dostępne jedynie dla starsze skrypty, a nie nowe. Podłączyłem również niestandardowe usługi sieciowe oparte na SOAP, z których jedno może być używane do wywoływania baz danych w systemie zdalnym, dając mi szeroką gamę narzędzi do testowania na poziomie integracji.

Podczas gdy język skryptowy jest w pełni funkcjonalny, wciąż rozwijam kompendium metod dostępnych domyślnie i wciąż próbuję ustawić go jako narzędzie do testowania integracji. Daj mi znać, jeśli pomoże lub nie - dlaczego nie spełnia twoich potrzeb, zawsze zadowolony z opinii! :)

PS: „Main” klasa jest dobrym miejscem, aby rozpocząć, aby uzyskać jego rozruch, ponieważ zawiera roboczą klienta CLI

Powiązane problemy