Napisałem ostatnio parę rozszerzeń do Mercuriala. Nic szczególnie skomplikowanego, rozwiązania codziennych uciążliwości (np. grupowe definiowanie aliasów albo automatyczne poprawianie numeru wersji przy tagowaniu).

Skoro już zdecydowałem się je opublikować, przydałoby się jakoś zapewniać jakość. A to oznacza przeprowadzanie podstawowych testów funkcjonalności przed każdym release. Co więcej, testy te warto by wykonać na różnych wersjach Mercuriala a nawet na różnych wersjach Pythona.

Przećwiczyłem w tym celu kilka narzędzi, które mogą być przydatne nie tylko w tym zastosowaniu (i nie tylko przy programowaniu w Pythonie).

Robię proste wyszukiwanie rekordu w jednej bazodanowej tabeli, po jednopolowym kluczu głównym. Wszelkie statystyki są policzone, dane mają normalny zdrowy rozkład. To musi działać szybko, nieprawdaż?

Też tak myślałem.

Zadziwiająco dużo praktycznych unit-testów wymaga realizacji sekwencji operacji. Aby sprawdzić, czy poprawnie działa kasowanie profilu dla którego istnieją zlecone operacje z przyszłą datą, trzeba najpierw ten profil stworzyć, potem zlecić owe operacje i dopiero można przejść do właściwego testu. Aby zweryfikować zachowanie trzeciej strony jakiejś sekwencji formularzy trzeba zasymulować logowanie, zainicjować sekwencję, przejść pierwszą stronę, przejść drugą stronę. I tak dalej…

Różnie można do tego podchodzić.

Przypomniałem sobie dzisiaj o polskim Pyconie i próbowałem znaleźć jakieś relacje i materiały (sam niestety w Ustroniu nie byłem, wybrałem w tym roku Front-Trends).

Zbyt wiele informacji niestety nie ma ale tym bardziej zdecydowałem się zanotować te znalezione.

Kawałek napisanego pythonowego kodu nieraz warto zamknąć jako bibliotekę i opublikować. W realizowanych czynnościach nie ma niczego trudnego ale ... wystarczy nie robić tego 2-3 miesiące, by nie pamiętać wszystkich kroków. Stąd ta notka.

Opisuję scenariusz, w którym publikuję i utrzymuję kod, który będzie można instalować przez easy_install (albo pip) i którego źródła będą dostępne dla wszystkich zainteresowanych.

Kawałek znalezionego gdzieś w sieci kodu, rzucającego przyjemny pomost między najstarszym z autentycznie lubianych przeze mnie języków programowania a tym, po który najchętniej sięgam dzisiaj.

Dla osób przesiadających się z C++ czy Javy to jedna z bardziej szokujących właściwości Pythona (a także Perla i paru innych języków skryptowych): kod programu można zmienić w locie. Można - w szczególności - dopisać albo podmienić metody istniejącej klasy czy funkcje zadanego modułu.

Technika ryzykowna, łatwo prowadząca do powstawania niezrozumiałego kodu i trudnych do interpretacji błędów. Ale zarazem bardzo przydatna, zwłaszcza gdy trzeba zmodyfikować zachowanie jakiejś biblioteki w miejscu, którego jej autor nie przewidział (np. ostatnio przypomniałem ją sobie chcąc zmienić sposób w jaki Mercurial obsługuje hasła HTTP i SMTP). Monkey-patching bardzo często przydaje się też przy testach, pozwalając zamienić prawdziwy kod komunikacyjny czy bazodanowy zaślepkami.

W tym artykule o kilku możliwych sposobach zapisywania tej operacji.

Wirtualne środowiska Pythona bez problemu można wykorzystywać także przy pracy z Jythonem (a także do przełączania się między Pythonem a Jythonem). Nie wymaga to żadnych szczególnych działań, wszystko przebiega niemal identycznie jak pod Pythonem.

Ostatnia część relacji z polskiego Pycona (pierwsza jest tutaj, druga tutaj a trzecia tutaj). Słowo się rzekło, kobyłka u płotu, rozpoczęte dzieło trzeba zakończyć a Pycon z to-do, blogerowi lżej.

Do omówienia zostały wykłady niedzielne, opisuję też co uważam za najważniejsze własne wnioski z konferencji.

Kolejna część relacji z polskiego Pycona (jeśli ktoś nie czytał - pierwsza jest tutaj a druga tutaj). Sobotni wieczór.