Firmy w Warszawie pracujące z Javą w metodyce TDD

Odpowiedz Nowy wątek
2019-02-07 19:27
0

W najbliższym czasie planowałem zmianę pracy, tym razem chcąc skupić się mocno na testowaniu aplikacji. Pracowałem w paru firmach, gdzie często mydlono oczy testowaniem aplikacji, a kończyło się to na pokryciu nie większym niż 1%. Próbowałem zachęcać kolegów z pracy jak i zarząd do testowania, jednak brakowało doświadczonych w tym obszarze osób jak i często czasu(argument, że odzyskuje się go na etapie utrzymania niestety nie pomagał).

Szukając opcji, chciałbym zapytać Was jakie firmy kojarzycie, które na pewno pracują z TDD?
WIem, że największy nacisk kładzie na to chyba Pragmatists, z WJUGów i ogłoszeń widziałem, że również Allegro. Parę osób wspominało mi również o Touk choć nie wiem czy dotyczy do wszystkich ich projektów.

Czy mielibyście może jakieś inne propozycje?

edytowany 2x, ostatnio: rapawopik, 2019-02-07 19:40
Ale w ogłoszeniach? To wszystkie. A rzeczywistości? Nieważne, ważne żebyś Ty znał wszystkie wzorce i algorytmy miał w małym palcu. :] - itsme 2019-02-07 19:28
Właśnie chciałbym uniknąć takiej miny, gdzie o TDD wspominają tylko w ogłoszeniu - a takich ofert jest niemało na nofluffie, justjoin, bulldogu i innych. Chciałbym żebym nie tylko ja praktykował takie podejście, bo i tak borykałbym się z ogromną ilością nieobtestowanego kodu, tak jak mam teraz. - rapawopik 2019-02-07 19:32

Pozostało 580 znaków

2019-02-07 19:55
1

TDD a kod pokryty testami to nie to samo. Możesz trafić w miejsce reklamujące się jako stosujące TDD i się srogo zawieść. Inne miejsce nie podające w ogłoszeniu TDD może za to mieć kod ładnie pokryty sensownymi testami (albo i nie sensownymi).


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
Czy mógłbyś rozwinąć na czym konkretnie mogę zawieść się w przypadku takich firm? I tak, zdaję sobie sprawę, z tego że jest to inna rzecz , chociażby miałem okazję porozmawiać z instruktorem na stacji.it, który z powodzeniem testował kod po jego zaimplementowaniu w projektach w jego firmie. Pytanie wynika raczej z chęci sprawdzenia się w takim podejściu w dużych, zespołowych projektach, a nie kolejnych, prywatnych code-katach. - rapawopik 2019-02-07 20:04
Chodziło mi po prostu o to że firma może podawać TDD i tego nie robić. Jeśli rozumiesz różnice to dobrze, z treści postu wynikało że mieszasz TDD z testowaniem ogólnie. Wspomniałeś pokrycie kodu testami, a to można osiągnąć bez żadnego TDD. - Aventus 2019-02-07 20:12

Pozostało 580 znaków

2019-02-07 20:03
5

A co za problem samemu pisać w TDD? Przecież możesz pójść do firmy, która nie pisze w TDD, zacząć robić TDD i wtedy ta firma może sobie wbijać TDD do swoich ogłoszeń ;). Poza tym, czasem trudno jest stosować tę metodologię, gdy naprawiasz jakiegoś buga, siedzisz z debugerem i nie wiesz, co jest przyczyną błędu. W takich sytuacjach najczęściej piszę testy na końcu, gdy już dojdę do właściwego rozwiązania. TDD można stosować, gdy dokładnie wiemy, jaki ma być końcowy efekt. Jeżeli jestem w takiej sytuacji, to stosuję TDD. Tak, czy inaczej, testy zawsze po sobie zostawiam. Nieważne czy przed implementacją, czy po. Jeśli Twoi koledzy w pracy tego nie robią, to może zrób jakieś szkolenie/pogadankę/pokaż zalety tego podejścia, powiedz o regresji błędów, a managerom możesz pokazać wykresy z coverage reportów i ich korelację z liczbą błędów, etc. W projektach, w których pracuję nie przepuszczam kodu bez testów (lub uzasadnienia braku testów) przez review. Inni też tak robią. Nie wyobrażam sobie teraz innego sposobu pracy, bo potem się tonie w błędach.

No ale nie mieszkam w stolicy, więc żadnej firmy Ci nie mogę polecić ;).

edytowany 4x, ostatnio: wiciu, 2019-02-07 20:06
managerom możesz pokazać wykresy z coverage reportów i ich korelację z liczbą błędów, masz może artykuł na ten temat? - lubie_programowac 2019-02-07 20:24
Niestety nie mam żadnego artykułu. Są to moje osobiste obserwacje i odczucia. Ogólnie rzecz biorąc, jak jest duży coverage, to trudniej coś zepsuć w aplikacji, bo od razu failują testy, co implikuje zapobieganie błędom zanim w ogóle wystąpią. Dodatkowo unit test na bug proof zapobiega regresji błędów. Może później poszukam jakichś fachowych podwalin tej teorii i jak znajdę jakiś artykuł lub inne źródło, to je tu podlinkuję. - wiciu 2019-02-07 20:25
Całkowicie się z Tobą zgadzam. Niestety doszedłem do takiej sytuacji gdzie prowadziłem szkolenia wewnętrzne i zwracałem uwagę na brak testów w merge requestach, ale liderzy projektów wciąż nalegali na przepchanie funkcjonalności(bo przecież jest gotowa, a testerzy sprawdzą, szkoda czasu). Po paru miesiącach stwierdziłem, że nie chcę już naprawiać świata, a zmienić firmę na taką gdzie to już dobrze funkcjonuję. Co do artykułu, może nie jest to porównanie o którym mówisz, ale również ważny czynnik o którym czytałem u Kenta Becka: (poniżej) - rapawopik 2019-02-07 20:48
Zagadnienie jest bardzo szerokie, chciałbym porozmawiać z kimś doświadczonym (takim jak Ty, robiłeś szkolenia wewnętrzne). Tutaj jest za mało miejsca. Ja w testowaniu stosuję zasadę pareto + BDD + powiedzmy metody formalne - tzn skupiam się na pisaniu kodu w taki sposób żeby nie można było popełnić błędu. Robię to m.in. z powodu wykresu którym się podzieliłeś: koszt naprawy błędu rośnie wykładniczo z czasem wydawania aplikacji. Wychodzę też z założenia poziom testów oraz kodu jest taki sam dla programisty więc warto robić cross testy. - lubie_programowac 2019-02-07 21:34
Z tym doświadczeniem to trochę za dużo powiedziane, bo szkoliłem z mojego obecnego stanu wiedzy, mało praktycznego. Stąd też stworzyłem ten temat, żeby znaleźć firmę gdzie takiej praktyki mogę nabrać. - rapawopik 2019-02-07 21:45

Pozostało 580 znaków

2019-02-07 22:03
1

Z ciekawości, co wzorcowe TDD wniesie do twojego życia i pracy?

Pozostało 580 znaków

2019-02-07 22:18
3
Satanistyczny Awatar napisał(a):

Z ciekawości, co wzorcowe TDD wniesie do twojego życia i pracy?

Nic! I na tym polega paradoks. Ludzie chca testowac i dostaja sraczki jak nie moga. Nie twierdze, ze to zle podejscie. TDD mozna sobie pocwiczyc w domu na wlasnym projekcie. Nie kazda technologia przygarnia TDD ale ludzie uparci i nic nie zrobisz :P


"Trolling is a art"
Tylko w czym rzecz? Nie demonizuję firm, które TDD nie praktykują, sam w ten sposób działam od lat. Zapytałem tylko o przykłady firm, które je stosują, tymczasem rozwinęła się tutaj dyskusja na temat zasadności jego stosowania. - rapawopik 2019-02-07 22:27
Twoje stwierdzenie jest złe. Ludzie nie chcą testować manualnie, bo to nudne i żmudne, więc lepiej testy sensowne napisać niż klikać jak idiota czy jakiś troglodyta z zamierzchłej epoki. Pisanie testów to w sumie jak programowanie. Piszesz sobie test i na bieżąco widzisz, że metoda zwraca to co chciałeś a nie programujesz w ciemno. Więc to nie tak, że ludzie chcą testować (zwłaszcza x różnych przypadków i przygotowywać dane pod te x przypadków), ale lepiej tak niż odpalać te serwery i dostać jakiś banalny błąd. - szarotka 2019-02-07 22:36
Której "poprzedniej epoki"? Testy automatyczne są praktykowane od co najmniej połowy lat 70tych (the Mythical Man-Month) mniej więcej kiedy to raz że terminale przestały być "maszynami do pisania" i zaczęły być skrzynkami z "zielonymi" szklanymi ekranikami i wprowadzanie programu za pomocą kart drukowanych czy przestawało być najpopularniejszą metodą wprowadzania programu oraz ludzie oswoili się dzięki systemom takim jak Multics i UNIX z wielozadaniowością i komunikacja między programami/skryptami, oraz wzrosła złożoność samego oprogramowania napędzająca m.in tą ideę. - Satanistyczny Awatar 2019-02-07 23:15

Pozostało 580 znaków

2019-02-07 23:32
3

A ja nie widzę sensu w klasycznym TDD, ani w tym co się rozumie dzisiaj przez "testy jednostkowe". Większość tego typu testów to testowanie Mockito (albo mocków w Spocku). O ile jeszcze rozumiem testy jednostkowe w przypadku mamy bardziej złożoną logikę i np. architekture portów i adapterów to tak, logike biznesowa testujemy jednostkowo. Ale sam nieraz widzialem nawet w prostych projektach przypadki że nie było sensu zrobić tzw. "testów jednostkowych" tylko lepiej po ludzku odpalić baze danych w pamięci, strzelić zapytaniem http i zrobić asserty czy JSON sie zgadza... Ze Spring Bootem to nie takie trudne :)


Nie pomagam przez PM. Pytania zadaje się na forum.

Pozostało 580 znaków

2019-02-08 11:30
2

Type driven development - jedyne prawiline TDD.

http://blog.ploeh.dk/2015/08/10/type-driven-development/

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0