Najlepsza odpowiedź
Obecnie pracuję dla AutoTrader, który moim zdaniem robi to bardzo dobrze.
Po prostu siadamy przed laptopem, z większym monitorem i klawiaturą / myszą, parujemy z jednym z naszych starszych programistów i obserwujemy przez innego starszego programistę.
To całkiem fajne wszystkich, pomijając zwykłe nerwy podczas rozmowy kwalifikacyjnej i fakt, że poznajesz nowych ludzi. Ale z pewnością, kiedy jestem twoją parą, staram się nawiązać odrobinę przyjaznej relacji, sprawić, że poczujesz się mile widziany i tak dalej. Tak jak zwykle. Tak naprawdę kibicuję ci, abyś odniósł sukces.
Otrzymujesz pół strony opis problemu prostego zadania. A potem trochę programujesz w parach.
Jest kilka rzeczy obserwowanych i punktowanych:
- Czy najpierw piszesz testy? Po kodzie? Nigdy?
- Czy używasz testów, aby przemyśleć projekt?
- Czy jasno określasz rzeczy?
- Czy preferujesz OOP, programowanie proceduralne – czy tylko jedno ogromna funkcja?
- Czy dobrze współdziałasz z tą parą? A może w ogóle?
- Czy wyjaśniasz swój sposób myślenia i zapraszasz parę do współpracy? Albo siedzieć w ciszy?
- Czy korzystasz ze standardowych udogodnień w Javie, takich jak Kolekcje? Jeśli nie, co robisz?
- Czy dobrze korzystasz z IDE (które wybierzesz)?
- Czy dobrze podzielisz problem? Słabo? Wcale nie?
Jeśli potrafisz zrobić Javę, TDD i / lub zaprojektować do testowania jednostkowego i wydajesz się być dość przystojnym typem, zwykle uzyskujesz wysokie wyniki.
W tym teście nie chodzi o znajomość dziwnych funkcji językowych ani dziwną znajomość algorytmów, ani nawet o rozwiązanie problemu.
Chodzi o to, aby zobaczyć, jak wykorzystujesz rzeczy, które napisałeś w swoim CV w prawdziwym życiu.
Naprawdę ci się spodoba. Daje wszystkim rzetelny obraz tego, gdzie jest kandydat.
Bezlitośnie usuwa również fałszywe roszczenia z CV.
Powiedz, że robisz TDD? Nie wiesz, co oznacza „assert”? O jej. Powiedz, że opanowałeś OOP? Cały kod, który nie działa, jest oparty na tej samej metodzie co dostarczony przez nas test jednostkowy? Ojej.
(I tak, to naprawdę się wydarzyło).
Dla mnie to, że jestem po obu stronach tego procesu, otworzyło oczy.
Odpowiedź
TDD to narzędzie. Co jest nie tak, to traktowanie TDD jako religii.
TDD jest zwykle wykonywane za pomocą testów jednostkowych: Testy małych części lub funkcji („jednostki” ) swojego kodu. Testy jednostkowe powinny działać szybko , więc generalnie makietujesz wszelkie zależności usług zewnętrznych i po prostu upewniasz się, że testowany jest sam kod.
Problem ogromnego słonia w pokoju polega na tym, że czasami te zewnętrzne usługi, z których kpiłeś, zawierają większość logiki funkcji. Jeśli Twoja „jednostka” pobiera element z bazy danych za pomocą zapytania i zwraca go, kpiąco , ta interakcja jest w 100\% bezużyteczna tylko jako substytut sprawdzania typów.
Powtórzę jeszcze raz w inny sposób: Tak zwani „przywódcy myśli ”Którzy głoszą ewangelię TDD również często głoszą ewangelię języków dynamicznych. Zatem języki, o których mówią, są o wiele bardziej produktywne w rzeczywistości testowanie wymaga znacznie więcej pracy, a często ponowne pisanie tych testów, gdy trzeba dokonać refaktoryzacji.
Napisz kod w bezpieczniejszym języku, takim jak C #, Java lub TypeScript, a nie Nie trzeba martwić się o weryfikację, czy typy są nadal aktualne. I istnieją tony rzeczywistych korzyści płynących z używania języków typu statycznego, oprócz konieczności pisania testów, które w rzeczywistości niczego nie testują.
Więc co tak naprawdę mam na myśli mówiąc, że „niczego nie testuję”? Załóżmy, że masz funkcję, która wysyła zapytanie SQL do Twojej bazy danych. Ma szukać elementów przefiltrowanych według określonego pola. Aby napisać szybki test jednostkowy, mockujesz zapytanie SQL. O ile Twoja pozorowana biblioteka nie może faktycznie symulować całej logiki PostgreSQL działającej na przykładowym zestawie danych, prawdziwa logika funkcji nie jest w ogóle testowana ; jedyne testy merytoryczne, które możesz napisać, aby zweryfikować logikę, potwierdziłyby jedynie, że Twoje makiety zwracały odpowiednie odpowiedzi.
Często widzę fałszywe po prostu „sprawdź, czy baza danych została wywołana odpowiednią liczbę razy”. W końcu to zapewniłoby Ci 100\% pokrycie kodu! Świetnie, liczba, która zaimponuje nietechnicznym menedżerom, która w praktyce nie oznacza absolutnie nic! Przejdź do zwodniczych statystyk zespołu!
Nie, potrzebujesz testów systemu lub testów integracji / E2E, aby sprawdzić, czy cały system jest pracujący. Nie tylko testy jednostkowe, ale także sprawdzenie, czy nie kpią z wywołań bazy danych, ale zamiast tego wykonują te wywołania.A kiedy zestaw testów musi wystawić rzeczywistą testową bazę danych, wyczyścić ją i wysiać między testami, powoduje to, że TDD jest praktyką niepraktyczną; jest za wolny.
Więc napisz najpierw kod, a następnie napisz swój test E2E i upewnij się, że daje prawidłowy wynik. Do licha, możesz użyć funkcji migawki zestawów testów, takich jak Jesthttps: //jestjs.io/docs/en/snapshot-testing, aby sprawdzić, czy odpowiedź się nie zmienia; spójrz na to raz, aby upewnić się, że jest poprawny, a gdy powiesz Jest, że to prawda, potwierdzi, że pozostanie niezmieniony w przyszłych uruchomieniach! Interfejsy API można testować i aktualizować ich testy w sposób prawie zautomatyzowany!
Więc jeśli zignorujesz bredzenie wiernych TDD, możesz wykonać swoją pracę dwa razy szybciej, ponieważ nie potrzebujesz czekać 10 minut (lub dłużej! Widziałem zestaw testów, który trwał ponad godzinę…) na uruchomienie pełnego zestawu E2E, aby zobaczyć test niepowodzenie zanim zaczniesz pisać kod.
Dodatkowo, testowanie interfejsu użytkownika w ogóle , jak wskazano w odpowiedzi Moray Taylor, to niepraktyczne w wielu okolicznościach. Istnieje jakiś poziom testu E2E, który można zastosować w interfejsie użytkownika, ale w większości przypadków zwrot z inwestycji rzadko wydaje się być tego wart w ogólnym przypadku.
To powiedziawszy, pracowałem nad biblioteką graficzną , która była kiedyś używana przez ponad sto różnych gier wideo i napisałem test E2E by sprawdzić, czy zmiana w wewnętrznej logice biblioteki nie zepsuje jakiejś niejasnej gry, której nigdy nie widziałem. Biblioteki zawsze zasługują na dokładniejsze testy. Ale w przypadku interfejsu użytkownika dla pojedynczej aplikacji testowanie E2E prawie nigdy nie ma sensu z mojego doświadczenia.