Aktywne Wpisy
Adammmo +41
Mirki wybaczcie zielone konto, śledzę wypok od lat, ale pierwszy raz sam muszę coś napisać. Mamy problem z sąsiadami w kamienicy.
Dziewczyna wykonując adaptację poddasza w 2012 roku nie uzyskała zgody od sąsiadów, aby przyłączyć się do istniejącej instalacji elektrycznej. Każdy z sąsiadów życzył sobie za to po kilka tysięcy, dlatego złożyła pismo do ENEA, aby wykonać pion instalacji samodzielnie. Od parteru, aż do siebie, na samą górę.
Dostała zgodę i tak
Dziewczyna wykonując adaptację poddasza w 2012 roku nie uzyskała zgody od sąsiadów, aby przyłączyć się do istniejącej instalacji elektrycznej. Każdy z sąsiadów życzył sobie za to po kilka tysięcy, dlatego złożyła pismo do ENEA, aby wykonać pion instalacji samodzielnie. Od parteru, aż do siebie, na samą górę.
Dostała zgodę i tak
Majkkelo +6
Ktoś mi wytłumaczy ten fenomen i zachwyt nad tym kanałem ? Serio nie macie swojego życia i każdy ruch najebusa sprawia wam tyle "xD". W mojej opinii skończy się to nieszczęściem, raz można się pośmiać, ale kogo to rajcuje tygodniami ? #danielmagical
Aktywne Znaleziska
~ E. Dijkstra
#programowanie
@Linux__Shines: wniosek?
Bugi w aplikacji zabijają :)
Tzn, traktuj TDD jako sposób na pisanie „specyfikacji kodu”, nie pisz nawet jednej linii kodu bez specyfikującego zachowanie testu.
W efekcie kod zachowuje się dokładnie jak tego sobie życzysz (nie ma błędów). Być może będą błędy projektowe, ale nie będzie błędu w kodzie, bo wyspecyfikowałeś pewne zachowania i w każdej chwili możesz zweryfikować, że są one działające.
Pozostają więc jedynie błędy projektowe (czyli np założenie, że
Nawet przy TDD nie ustrzeżesz się błędów w kodzie, bo i w teście możesz popełnić błąd/nie wziąć czegoś pod uwagę. Finalnie będzie jeszcze gorzej, bo będziesz miał błąd, który nie wywala testu - będziesz uważał, że jest ok.
@KotoFan: Błędu w kodzie mieć nie będziesz – będziesz miał błąd w specyfikacji. Tzn robiąc TDD mówisz czego oczekujesz od kodu.
Jeśli oczekujesz za mało lub oczekujesz rzeczy, których nie powinieneś, to oddzielna bajka. Przechodzący testy kod zachowa się jednak poprawnie, wedle oczekiwań.
Kwestia sporna. TDD ma bardzo wiele zalet, ale ma także dość sporo wad. Jak choćby ta, że w praktyce #it specyfikacja zmienia się przez pierwsze tygodnie od początku implementowania (tak, teoria mówi co innego, ja mówię o praktyce) i jak zaczynasz od testów, to potem okazuje się, że połowa z nich jest nieaktualna.
TDD jest świetne, jak doskonale wiesz co robisz i jak dziedzina, w której piszesz jest w 100%
Por.
_R. Niemal niemożliwe jest napisanie testów pokrywających wszystkie edge case do takich funkcjonalności jak np.:
*
_R.isValidVariableName*
_R.getInternalClass*
_R.indirectEvalProces TDD jest właśnie sposobem na uniknięcie błędów w kodzie – piszesz czego wymagasz od kodu, a potem implementujesz to. W każdej chwili możesz sprawdzić czy kod spełnia reguły „formalnej specyfikacji”, jaką jest kod testujący.
I tak jak pisałem wcześniej, „jeśli oczekujesz za mało lub oczekujesz rzeczy, których nie powinieneś, to oddzielna bajka.”
@Ragnarokk: I właśnie po to jest TDD, żebyś po zmianie wymagań mógł bezpiecznie zmienić implementację. TDD daje Ci pewność, że zmienisz tylko to co jest od Ciebie wymagane, a wszystko inne będzie dalej działać bez zarzutu.
TDD = Test Driven Development, nie piszesz nowego kodu dopóki nie masz
@Ginden: Zgadza się, dlatego pisałem:
Dlatego nie twierdzę, że można wyeliminować wszystkie błędy w aplikacji – twierdzę, że można wyeliminować błędy w kodzie aplikacji. Że implementacja będzie bezbłędna – w zakresie jej specyfikacji (testów ;-)).
Przy okazji TDD/BDD realnie przyczynia się do zmniejszenia liczby błędów także w aplikacji – bo wymaga zastanowienia się nad różnymi
Wszystko to statystyka i prawdopodobieństwo. Trzeba dążyć do 100% pokrycia, ale na pewno się tego nie osiągnie.
Ogólnie TDD wydaje mi się bardzo spoko, ale moje doświadczenie z tym polega tylko na kilku ćwiczeniach.
Ogólnie jeżeli piszesz w TDD, to twój kod jest testowalny i gotowy na refaktoring. W dowolnym momencie - nawet przy zmianie założeń.
W końcu TDD zbliża cię zawsze do celu i funkcjonalności, czyli traktowanie klas
@patrolez:
Na ostatniej konferencji na której byłem był cały wykład o tym, że wcale nie.
@MacDada:
Zależy jak bardzo się wszystko zmieni. Jak zmienią się tylko wartości, to masz rację. Jak przełożony nagle powie, że zmieniamy całą architekturę i ma być gotowe z końcem tygodnia, to już większy problem ( ͡° ͜ʖ ͡°)
Ogólnie mam wrażenie, że traktujesz TDD/BDD jako jedyną
Chodzi o współtworzenie testów i kodu produkcyjnego, a nie pokrywanie już istniejącego kodu.
Wtedy kod produkcyjny weryfikuje testy i testy weryfikują kod produkcyjny.
Tak się składa, że właśnie Uncle Bob testuje i pisze z TDD.
W sumie, to jego doświadczeniem się inspiruję :P
Trochę się rozmijamy w zrozumieniu nawzajem. TDD jest bardzo dobre, tylko mówię, że nie jest to zawsze i uniwersalnie najlepsze rozwiązanie. Sam korzystam, kiedy mogę. Natomiast chodzi mi o to, że są w pracy zawodowej sytuacje, że ta idea nie do końca spotyka się z praktyką. Taki Uncle Bob chyba nie ma nad sobą przełożonych, którzy mu mówią, że coś musi być zrobione na wczoraj, więc może rozwijać swoje oprogramowanie
TDD sprawia, że kod jest niezawodny.
Niesie za sobą koszta i o tym nie dyskutuję. Aczkolwiek widziałem opinie (i badania z doświadczenia firm), że koszta pisania z TDD są mniejsze niż koszta wynikające z niepisania TDD. Ale nadal
Na dłuższą metę koszta mogą być jak najbardziej mniejsze przy użyciu TDD, tutaj nie mam wątpliwości. Maintainowanie zbugowanego kodu jest kosztowne i #!$%@?ące. Początkowo, przy samym starcie są mniejsze, po latach się powinno spokojnie zamortyzować i dać zysk.
W sprawie niezawodności - w testach mozna popełniać błędy jak w każdym innym miejscu. Niezawodna jest tylko śmierć :)