Zine.net online

Aż dziw bierze, że można pracować bez ciągłej integracji kodu.

Świetna sprawa. Zarówno sam pomysł tych "cast'ów" jak i pomysły tematów.

Pytanie odnośnie testów jednostkowych: wspomnieliście, że odbywają się automatycznie na serwerze, po wrzutkach kodu do repozytorium, i mogą trwać trochę czasu.

Czy w takim razie programiści nie odpalają testów na swoich lokalnych maszynach (bo zrobi to za nich serwer), czy też uruchamiają jakąś odchudzoną ich wersję?

Oczywiście programista odpala swoje testy lokalnie, natomiast serwer odpala wszystkie, żeby sprawdzić czy przypadkiem nie namieszaliśmy w czyimś kodzie (np. zmieniając klasę, której ktoś inny używa).

Tarciu, nuwanda juz wlasciwie odpowiedzial na pytanie. Dodam tylko, ze programista przed commitem zmian powinien odpalic wszystkie testy, nie tylko swoje.

Dodatkowo czesto to co testy przepuszcza na maszynie developera zakonczyc sie moze bledem w niezaleznym srodowisku.

To ja proponuję temat na następną rozmowę - testy jednostkowe :)

Jeśli chodzi o mnie, to jestem w tym zupełnie zielony i chętnie posłucham rozmowy osób, które mają już z nimi doświadczenie.

Ciekawe, czy znajdzie się ktoś, kto brał udział w jakimś poważniejszym projekcie gdzie zastosowanoby prawdziwe TDD.

Ziemku, chciałem się odnieść do omawianej przez Ciebie opcji rozwiązywania bugów dopiero po przetestowaniu na serwerze integracji (40 minuta). Taki proces zakłada, że zgłoszenie buga będzie implikowało stworzenie co najmniej jednego przypadku testowego, który nie przechodzi, gdy bug jest i przechodzi, gdy zostanie on poprawiony. Moje pytanie: czy istnieją takie systemy śledzenia błędów, które pozwalają wiązać bugi z pewnym zbiorem testów?

Co do problemów z rozwiązywaniem bugów wraz z commitem to też napotkałem pewien problem (na co dzień pracuję z TFS). Otóż jeżeli częścią rozwiązania jest modyfikacja schematu bazy danych to nie zawsze jest możliwy natychmiastowy update schematu bazy dla całego projektu, w szczególności, gdy zajmuje się tym jedna osoba. Jeżeli zapomnimy o tym i wrzucimy źródła na serwer, bug zostanie rozwiązany a tester dostanie wiadomość, że kolejny build będzie zawierał tę poprawkę. Jeżeli weźmie ten build przed wprowadzeniem zmian w schemacie bazy danych, to może się okazać, że u niego ten bug nadal będzie się pojawiał. Z drugiej strony przetestowanie takiego scenariusza jest dość kłopotliwe, gdyż wymaga utworzenia nowej bazy danych, na której musiałyby działać testy jednostek…

Podobało mi się, tylko jedno 'ale'

To co Ziemek powiedział po ok. 1h, powinno znaleźć się bliżej wstępu. Chodzi mi o to co zamiast CI, gdy projekt jest duży (myślałem, że się już nie doczekam).

nuwanda:

wydaje mi się, że tester nie powinien mieć możliwości uruchomienia programu na poprzedniej wersji bazy. I powinno się to rozwiązać programowo (stosuję automatyczną konwersję struktury bazy przy starcie programu)

#arturstan: Testerzy nie mają starej wersji bazy. Gdy testują inny build to wykorzystują do testów bazę generowaną przez generator z builda, który testują. U mnie schemat bazy jest razem z kodem w repozytorium a generator baz kompiluje się razem z całym projektem. Zatem jeżeli osoba odpowiedzialna za update schematu nie zrobi update'u przed buildem to generator w nowym buildzie wygeneruje starą bazę. Więc siłą rzeczy tester będzie miał starą bazę.

nuwanda:

Co do pytania, to osobiscie sie nie spotkalem z takim rozwiazaniem "pod klucz". Moze istnieja lecz nic o tym nie wiem. W kazdym razie nic nie stoi na przeszkodzie aby jakos to powiazac poprzez atrybuty, opis testu czy cos innego. Jest to metoda chalupnicza oczywiscie ale jak to mawiaja, z "braku laku dobry kit".

Co do TFS to sie pozwole niezgodzic z Twoim zdaniem, ale jest jeden warunek: uzywamy VS for Database Prof. do robienia zmian w bazie danych. Wtedy jak najbardziej jestesmy w stanie realizaowac wspomniana metodyke.

Ogolnie rzecz biorac, to developer nie powinien robic zmian w bazie. Jesli juz mowimy o tym jak to powinno byc w wiekszej organizacji. W malych oczywiscie, kazdy sam orze, sieje i kosi. W duzych organizacjach natomoast do zmian w bazie danych powinien byc osobny team i on uzywa stosownych narzedzi.