Autor: Commander

Testy protokołu WebSocket

Obuplikowano: | przez: Commander

Coraz częściej, użytkownicy aplikacji oczekują od niej działania w czasie rzeczywistym – dotyczy to nie tylko rozmaitych komunikatorów (to przykład, który najłatwiej sobie wyobrazić), ale wszystkich aplikacji, które wyświetlają dane, mogące się często zmieniać. Użytkownik nie chce odświeżać strony/widoku tylko po to, żeby sprawdzić czy interesujące go dane się zmieniły, lub otrzymał nową wiadomość na czacie.

Można spróbować wprowadzić rozwiązania oparte na protokole HTTP, np. wysyłanie w krótkim interwale czasowym zapytania po nowe wiadomości. Łatwo sobie jednak wyobrazić, że takie podejście generuje ogromny ruch i obciąża serwer, który co chwile musi odpowiadać „Nie ma żadnej nowej wiadomości.”

Rozwiązaniem tego zagadnienia może być protokół WebSocket, zapewniający dwukierunkowy kanał komunikacji za pośrednictwem jednego gniazda TCP.

Czytaj dalej

Atomówki

Obuplikowano: | przez: Commander

Celem testów automatycznych jest znalezienie błędów. To oczywiste, jednak testując oprogramowanie nie można ograniczać się wyłącznie do stwierdzenia „Nie działa” (chyba że chcemy bardzo szybko utracić sympatię programistów). Dobrze napisane testy powinny jasno określać co i w jakich okolicznościach nie działa.

Co zrobić, żeby nasze testy automatyczne były rzeczywiście pomocne w procesie rozwoju oprogramowania?

Czytaj dalej

Page Object Pattern i Apium

Obuplikowano: | przez: Commander

Duplikaty i zmiany

Wyobraźmy sobie, że otrzymujemy zadanie przetestowania głupkowatej aplikacji, której mechanikę prezentuje poniższy diagram:

Użytkownik po zalogowaniu się może wybrać jedną (lub wiele) opcji, dodać (lub nie) komentarz oraz potwierdzić działanie. W rezultacie trafia na widok prezentujący informację o sukcesie lub porażce. Czytaj dalej

Ścieżka

Obuplikowano: | przez: Commander

Anegdotka

Padawan zaczął swoją pierwszą pracę, zainstalował niezbędne elementy środowiska, odpalił emulator Androida, trzymając się dokładnie wytycznych otrzymanych od nas i wspierając się internetem.

Ściągnął ostatni build aplikacji, przeciąga plik *.apk żeby zainstalować i błąd „APK Installer The APK failed to install. Error: Could not parse error string”:

Mało wyjaśniający komunikat, nieprawda?

Zebrało się konsylium, sprawdzamy JavaJDK, Instalację Google Play Services, czyszczenie cache Android Studio, Eksport-Import ustawień, nic nie działa! Błąd jak był tak jest.

Próbujemy zainstalować z konsoli, żeby było wygodniej, przerzucamy plik z aplikacją do katalogu, w którym jest adb (nie chciało mi się całej ścieżki kopiować). Magia! Działa.

No to próbujemy jeszcze raz: drag&drop ciągle zawodzi.

Okazało się, że Padawan miał w nazwie katalogu, w którym trzymał aplikację „&” i to, w (tylko w jego konfiguracji systemu – u mnie działa) powodowało błąd.

Morał

  1. Sprawdzać proste rozwiązania;
  2. Nie używać żadnych znaków specjalnych w nazwach katalogów, jakby nowoczesny nie był system;
  3. Głupotki mogą spalić sporo czasu.

Appium – wprowadzenie

Obuplikowano: | przez: Commander

O Appium

Istnieje sporo narzędzi do automatyzacji testów e2e aplikacji mobilnych, część z nich przeznaczona jest do pracy z systemem Android, część do iOS, takie rozwiązania są bez wątpienia najlepsze, jeżeli pracujemy nad aplikacją przeznaczoną dla jednej platformy. Jednak w sytuacji kiedy przygotowywana jest aplikacja dla dwóch platform: lepiej jest wybrać narzędzie, które pozwoli przygotować automatyczne testy na obie platformy.

Jednym z takich rozwiązań jest Appium.

Założeniem twórców Appium było stworzenie open-source’owego rozwiązania, pozwalającego na:

  • Testowana powinna być niezmieniona wersja aplikacji;
  • Narzędzie do testów nie powinno ograniczać użytkownika do korzystania z jednego języka;
  • Maksymalizacja reużywalności testów dla wszystkich platform (brak konieczności pisania odrębnego kodu dla testów na Androidzie oraz iOS).

Czytaj dalej