@axelbest: tak mi się skojarzyło z Twoim linkiem:

Pewien mężczyzna kupił dojarkę do celów erotycznych.
Wrócił do domu, zasiadł w fotelu i podłączył się do ssaka od dojarki.
Przeżywał orgazm za orgazmem, nigdy jeszcze tak dobrze mu nie było.
Po dwóch godzinach ma w końcu dość, szuka wyłącznika - nie ma.
Próbuje oderwać ssak od własnego interesu - nie da rady.
A dojarka cały czas ssie.
Z wielkim trudem łapie za telefon i dzwoni do producenta:

• Dzień dobry, ja u państwa kupiłem dzisiaj dojarkę, chciałbym się dowiedzieć, jak się ją wyłącza.
• Przede wszystkim - odpowiada sprzedawca - chciałbym pogratulować panu doskonałego wyboru, gdyż jest to produkt najwyższej marki.
• Dobra, dobra, ale gdzie się go wyłącza.
• Nasza dojarka wyłącza się automatycznie po uciągnięciu 25 litrów.

Pewien profesor na wydziale matematycznym uniwersytetu po zagmatwanej odpowiedzi studenta powiedział
prof: ech, wiesz po czym poznaje się człowieka rozumnego?
stud: ...
prof: po tym, że komunikuje się w zrozumiały sposób. Rozumiesz?
stud: ...nie

"Dzwony dzwonią ale nie wiadomo w którym kościele" - tutaj prezentujecie inne podejście https://www.spreaker.com/user/devenv/devcast-06 ~4:25 "Mieliśmy dużą ilość testów na różnych poziomach którym kompletnie nie był w stanie zaufać. Nie były deterministyczne. [...] Spotykasz dużą ilość testów, sam brak nie musi być rzeczą negatywną bo ich nadmierna ilość albo ich wadliwa jakość też może nie być dobra dokumentacją projektu. " Pragmatyzm ponad dogmatyzmem - tzn KPI / cel aby osiągnąć 100% test coverage nie jest dobrym. Dobry programista pisze dobre testy, tworzy dobrą architekturą, tworzy dobry design.

Osobiście jestem zdania że testy jednostkowe należy ograniczyć do minimum, tam gdzie naprawdę maja one sens. Np. mam jakąś klasę enkapsulujacą operacje na czasie, wtedy chce ja oddzielnie pokryć testami jednostkowymi aby sprawdzić każdy przypadek użycia. W każdym innym razie zdaje się na testowanie konkretnego scenariusza w obrębie danej aplikacji/serwisu. Podmieniam zewnętrzne zależności (inne serwisy, bazy danych itp.) natomiast (zakładając aplikację webową) w teście stawiam wirtualny host, wykonuje jakiś request i sprawdzam wynik. W ten sposób testowany jest cały pipeline danej operacji. Osiągam te same profity co przy użyciu testów jednostkowych, ale bez niepotrzebnego rozdrabniania się i kilku/kilkunastu testów wyrwanych z kontekstu, w miejsce jednego który właśnie tenże kontekst testuje.

Ciekawe, czemu nie da się tego odpalić na Windowsie...

Pad na zdjęciu jest nie od NESa tylko od Super Famicoma, japońskiej wersji SNESa (nie NESa)

@LukeJL: pair programming chcesz zrobić z osobami, które rokują na zatrudnienie, a takich wiele nie masz (w puli). Wierz mi, że nie chcesz tego robić z każdym kandydatem, który wysłał CV i naumiał się odpowiedzi "dlaczego chce Pan zmienić pracę" + poczytał i wykuł "interview questions" z tematyki "requirements", bo jeśli na stanowisko przychodzi dużo CV, to Twój team niczym innym by się nie zajmował, tylko właśnie tym.

@Afish średni ten wniosek, tak samo można powiedzieć, że jak na rekrutacji pytają o nowe frameworki, to będziesz używał ich w projekcie. - i tego bym oczekiwał, podobnie jak zadania są z JSa, to oczekiwałbym pracy w JSie (zdarzyło mi się, że po pytaniach testowych z zaawansowanego JSa trafiłem do projektu, w którym 90% to było klepanie formatek w CSS). Zbyt wielka różnica między testem, a faktycznymi wymaganiami w pracy sprawia, że przestaje mieć to sens. Z drugiej strony, sporo kodu jest kijowa, więc może lepiej, gdy firma mówi o tym wprost. - fakt, kiedyś dostałem zadanie domowe w stylu real life, w którym musiałem dorobić ileś ficzerów w bardzo słabo napisanym kodzie i wysłać do repo. W tamtym przypadku myślę, że faktycznie chciano sprawdzić, czy umiem hakować spaghetti xD