Kabu napisał(a): No ale dobrze by bylo aby ktos inny przetestowal kod napisany przez "generycznych developerow"...
Ogolnie niech zgadne - w robocie korzystacie z TDD i DDD? Nie wiem czemu ale sporo osob, ktore zaczyna tego uzywac (lub uzywa tylko tego w pracy) uwaza ze developerzy wykorzystujacy to sa swietni. Natomiast osoby korzystujace z innych wzorcow (np anemic domain model/transaction script) sa mierne. No i na koncu zazwyczaj udowadniaja ze swietni devsi piszacy w tdd/ddd napisza lepszy soft niz mierni w innych technologiach. Jakos zawsze umyka im ze w swoich rozwazaniach za bardzo skupiaja sie na ludziach.
Wogole co to jest generyczny tester? Jesli mamy generycznego testera to mamy i generycznego developera i caly projekt idzie wpizdu. Zaloz ze mozna miec doby zespol testerski, ktory rozumie domene (zespol z ludzmi tak samo wartosciowymi jak developerzy). I wnosi duzo dobrego. Oczywiscie jesli wszystko sami testujecie to moze i to dziala dobrze u was. Ale przypuszczam ze przy dobrym zespole testerskim i dobrym procesie byloby lepiej. Idac Twoja logika mozemy zalozyc ze cala idea devops to tez pomylka bo programista moze ogarnac swoj kod. I faktycznie moze lecz w duzych projektach/firmach zaczynaja sie pojawiac ludzie, ktorzy praktycznie tylko tym sie zajmuja i z mojego punktu widzenia to sie sprawdza. Oczywiscie z zespolem testerskim jest sporo problemow: trzeba za nich placic, zatrudnia sie studentow/osoby z indii liczac ze to wystarczy itp (ogolnie testerow wiele osob ciagle traktuje jako tania sile robocza).
Ps
Zeby nie bylo - uwazam TDD i DDD za podejscia, ktore sie sprawdzily (DDD samym "wspolny" jezykiem i naciskiem na bounded contextem wniosl wystarczajaco duzo aby stac sie podstawa, ktora kazdy musi znac).
Zgadłeś TDD od lat. A DDD od dwóch. Z tym, że już się nauczyliśmy, że sedno DDD - strategic patterns (UL, context mapy itd.) stosuje się tylko w core domain, a DDD lite, tactical patterns, to po prostu dobrze napisany OOP. Dlatego nie traktujemy anemicznych encji i transaction script jako coś z góry złe. Wszystko zależy od skomplikowania domeny. Zresztą tego też uczy TDD, że zaczynasz od prostych implementacji, bez narzutu wielu wzorców, a później refaktorujesz w miarę potrzeb.
Co do DevOps to w żcyiu bym nie powiedział, że są niepotrzebni, są zajebiście potrzebni i u nas jest niestety ich niedostatek. Różnica między dedykowanym DevOpsem i dedykowanym testerem jest taka, że DevOps nie musi znać dobrze domeny, a tester moim zdaniem musi. Oczywiście, jeżeli pracujecie nad jednym produktem cały czas, to stały tester będzie miał duże pojęcie o danej aplikacji i na pewno wniesie więcej niż tester przydzielany z doskoku.
Taki tester rzeczywiście może znaleźć miejsca, które nie zostały otestowane, tu sie zgadzam. Największym problemem developera przy testach jest znalezienie wszystkich przypadków do otestowania, jak o którymś zapomnisz to mogą być niezłe kwiatki.
W każdym bądź razie nadal uważam, że osoba, która zajmuje się tylko testami nie będzie w stanie pisać dobrych testów automatycznych (czyli takich które się nie wysypią po najmniejszym refactorze, nie będą uciążliwe w utrzymaniu i przede wszystkim będą czytelne), a na testy manualne przeważnie szkoda zasobów.
Jeszcze wracając do DDD i Bounded Context - granice contextu idealnie wyznaczają microservice dzięki czemu w końcu odeszliśmy od monolitu, ale teraz potrzeba nam dużo więcej devopsów.
|
Czesc osob uwaza, ze trzeba pisac tak dobry kod, zeby nie bylo potrzeba testow 
A i tak mamy to niezle zautomatyzowane. Debugowanie przy udziale kilku modulow jest problematyczne, najczesciej trzeba szukac w logach serwera bo lokalnie nie odpale, albo za duzy trud by to zrobic. No i jeden modul jest za duzy co tez sprawia problemy. Testowanie tez takie proste nie jest. 
