2009-10-20 15 views
15

Jestem przede wszystkim facetem Ruby, ale ostatnio pracowałem nad wieloma rzeczami w Pythonie, w szczególności nad kodem App Engine. W Ruby użyłbym automatycznej ciągłej integracji (autotest), narzędzi do analizy kodu (rcov), analizy statycznej (reek) i testowania mutacji (heckle) w moim procesie rozwoju, ale nie jestem pewien, jak najlepiej skonfigurować podobny proces rozwoju środowiska App Engine. Byłbym również zainteresowany analogami do RSpec i Cucumber dla Pythona, który mógłby działać w App Engine.Jak mogę skonfigurować proces rozwoju TDD za pomocą Google App Engine?

+3

to absolutnie niesamowite kultura TDD, który powstaje wewnątrz społeczności Ruby. –

Odpowiedz

15

na moim projekcie GAE, używam:

  • NoseGAE — To jest najważniejszy kawałek, który łączy wszystko reszta razem
  • Makiety, jak w doskonałej odpowiedzi Jana. Używam tego w dużej mierze na AWS i innych usług internetowych
  • Lampy (opakowania, nie chodzi)

ja też preferuje wielu idiomów Rails jest. Zniszczyłem moje testy na jednostkę i funkcjonowałem używając pakietów Pythona. Można uruchomić podzestaw testów przy użyciu --tests=unit lub --tests=functional. To wszystko jest trochę bardziej ręczne niż Railsy, ​​ale przynajmniej mogę przetestować sprzęt i upewnić się, że nigdy nie mam regresji.

Wykonałem również prostą klasę FunctionalTest, aby wykonać wiele typowych akcji w Railsach, takich jak assert_response i assert_xpath (podobnie jak assert_select).

class FunctionalTest(Test): 
    def get(self, *args, **kw): 
    self.response = app.get(*args, **kw) 

    def post(self, *args, **kw): 
    self.response = app.post(*args, **kw) 

    def assert_response(self, expected): 
    pattern = str(expected) if re.search(r'^\d+$', expected) \ 
          else (r'^\d+ %s' % expected) 
    assert re.search(pattern, self.response.status, re.IGNORECASE), \ 
      'Response status was not "%s": %s' % (expected, self.response.status) 

    def assert_xpath(self, path, expected): 
    element = ElementTree.fromstring(self.response.body) 
    found_nodes = element.findall('.' + path) 
    if type(expected) is int: 
     assert_equal(expected, len(found_nodes)) 
    elif type(expected) is str or type(expected) is unicode: 
     assert (True in [(node.text == expected) for node in found_nodes]) 
    else: 
     raise Exception, "Unknown expected value: %r" % type(expected) 

Jeśli robisz dużo ListElement wyszukiwań równości, na pewno nauczyć się składni --tests=foo ponieważ testowanie dopasowywania elementów w liście jest bardzo powolny.

Czasami lubię ładować konsolę Rails do danych mojego urządzenia, aby zobaczyć, co się dzieje w środowisku testowym (np. script/console test). Zrobić coś podobnego z GAE, uruchom dev_appserver.py z parametrem --datastore_path="$TMPDIR/nosegae.datastore" (ewentualnie zastąpić /tmp dla $TMPDIR.

+0

Przyjęto tę odpowiedź dla krytycznej informacji NoseGAE, chociaż odpowiedź Johna była niezwykle pomocna. –

+0

Dzięki, Bob! W istocie planuję włączyć więcej propozycji Johna do moich własnych projektów w przyszłości. – JasonSmith

+0

Bob, przechodząc z powrotem przez mój kod, zauważyłem, że miałem sposób na uruchomienie normalnego serwera SDK względem magazynu danych utworzonego przez NoseGAE, więc dodałem to jako ostatni akapit. – JasonSmith

26

Nie zawsze znajdziecie jeden do jednego odpowiednika narzędzi testujących Ruby w Pythonie, ale w Pythonie jest kilka świetnych narzędzi do testowania. Niektóre narzędzia, które znalazłem przydatne, to:

  • unittest - narzędzie xUnit dołączone do standardowej biblioteki Python. Obejmuje on wszystkie podstawy testów jednostkowych.
  • doctest - niesamowita część standardowej biblioteki, pozwala pisać testy w docstruuje funkcje, klasy, moduły, metody. Jest świetny w przekazywaniu zamierzonego wykorzystania API. Ian Bicking sugeruje użycie doctest do Behavior Driven Development. Doctest bardzo dobrze pasuje do systemu dokumentacji Sphinx (możesz upewnić się, że wszystkie przykłady w dokumentacji są przekazywane za każdym razem, gdy budujesz dokumenty).
  • nose i py.test są postrzegane jako kolejne wersje wersji unittest. Mogą uruchamiać wszystkie istniejące przypadki unieważnione, ale pozwalają na łatwiejsze, niezależne od klasy testy jednostkowe. py.test pozwala również na rozproszone wykonanie.
  • mock to fajna biblioteka do szyderczego zachowania.
  • tdaemon obserwuje katalog aktualizacji kodu i ponownie uruchomi pakiet testowy. (mój personal branch zawiera kilka niezmodyfikowanych ulepszeń).
  • Buildbot, Bitten, a nawet Hudson wszystkie działają dobrze jako pełnoprawne serwery integracji ciągłej dla kodu Python.
  • coverage.py oblicza zasięg kodu twojego kodu.
  • pylint dostarczy lintopodobną analizę kodu, upewniając się, że jest zgodna z typowymi konwencjami kodowania i nie ma żadnych typowych błędów. Istnieje również "lżejsze" narzędzie analityczne, PyFlakes.
  • Istnieje wiele narzędzi do testowania HTTP/przeglądarki, które działają dobrze w języku Python, w tym Twill, Selenium i Windmill.

Jeśli korzystasz z Django w App Engine, zawiera on several extensions, aby umożliwić testowanie, które pozwala symulować zachowanie klienta HTTP i bazy danych.

Istnieje wiele innych narzędzi, których nie używałem (takich jak PySpec i Behaviour), które również mogą być pomocne. Nie widziałem żadnego narzędzia do testowania mutacji w Pythonie, ale założę się, że jest tam jeden (chciałbym się dowiedzieć, co to jest).

Zadowolony test!

+3

favoriting to pytanie wyłącznie dla tej odpowiedzi –

+0

wiele fantastycznych linki tutaj. Zgaduję, wiele z nich nie rozwijanym w przypadku GAE. Chciałbym zobaczyć więcej odpowiedzi opisujących, w jaki sposób zostały zintegrowane ze środowiskiem programistycznym GAE, szczególnie z OS X launcher. –

+1

Bob, odpowiedź Johna jest naprawdę dobra. Jak już powiedziałem poniżej, po zainstalowaniu wtyczki NoseGAE dla Nosa jest to prawie płynne żegludze z tymi wszystkimi narzędziami. – JasonSmith

3

nie wykorzystali App Engine, ale moje uczucie do najbardziej popularnych narzędzi do testowania pyton jest

  • unittest/doctest są pakiety testowe od standardowego biblioteki Pythona. unittest to xUnit dla Pythona.
  • nose to biegacz/wyszukiwarka. Ma wiele opcji, w tym --with-coverage, która używa coverage, aby otrzymać raporty na temat zasięgu kodu .
  • pylint to najbardziej funkcjonalny sprawdzian szarpie dla Pythona. Przydatne poza sprawdzaniem składni, ponieważ zaleca nieużywane zmienne/funkcje, gdy metody powinny być funkcjami i nie tylko.
  • pester (badanie mutacji)
  • buildbot (ciągła integracja)

Prawdopodobnie będziesz chciał odwoływać się do tego (nie całkiem kompletna) wykaz Python Testing Tools.

W przypadku BDD pole było cienkie, gdy ostatni raz sprawdzałem. Wiele z prawdziwych narzędzi BDD nie nadaje się do użytku z nosem i/lub zbyt ograniczeniami w wymaganej składni. Możesz mieć trochę szczęścia z spec, która jest wtyczką typu BDD-like nose. Właśnie znalazłem pyccuracy, który wygląda jak ogórek, ale nie wypróbowałem go.

Na co warto, to teraz wystarczy użyć nosetests -v (biegacz nos z --verbose), który będzie korzystał z pierwszej linii docstring w prowadnicy testu wyjściowego. Oznacza to, że dany test jak:

class TestFoo(unittest.TestCase): 
    def testAnyNameHere(self): 
     """ Foo should be bar""" 
     foo = "bar" 
     self.assertEqual(foo, 'bar') 

nosetests dadzą:

$ nosetests -v 
Foo should be bar... ok 

----------------------------- 
Ran 1 tests in 0.002s 
OK 
+0

+1 za pester wspomnienie –