Wibowit napisał(a):
Dyscyplina się nie skaluje. Jak zauważył @jarekr000000 kontener DI ułatwia mnożenie zależności. Prawa Murphy'ego działają - jeżeli istnieje nieznikoma szansa, że zaplątamy się w sieć zależności to to się stanie.
No dobrze, ale ktoś nad tym stadkiem seniorów powinien jakoś panować, review robić. Sonar powinien liczyć powiązania i alarmować, gdy coś się rozrasta. No, i najważniejsza rzecz - edukacja.
Ojejciu, ale żeś pojechał. Może pokażesz przewagę tego wspaniałego C# nad Javą?
Widzę, że niektórym się płyta zacięła. :P Nie twierdzę, że C# jest wspaniały, w ogóle nic o nim nie pisałem.
Nie widzę specjalnie jak C# ułatwia przekazywanie zależności porównując do Javy.
W żaden sposób.
Niemniej jednak, @jarekr000000 sporo tutaj na Javę i jej frameworki narzekał - tylko do tego się odnosiłem. Coś ewidentnie w ekosystemie Javy jest nie tak.
Z drugiej strony, w .NET mamy zdaje się port Springa i jeszcze parę kontenerów, które wspierają konfigurację poprzez XML. Tylko tu znowu problemem są ludzie, którzy piszą (albo każą innym pisać) te XMLe. A drugim problemem są bezwolni programiści, którzy robią to, co im jakiś lead/architekt każe, kompletnie bezrefleksyjnie i bez próby jakiegokolwiek zakwestionowania idiotyczności niektórych pomysłów.
Ponadto w Scali są takie bajery jak argumenty implicit (w Javie wszystkie argumenty są explicit) czy miksowanie traitów, które mogą zawierać stan (interfejsy w Javie nie mogą zawierać stanu) co razem daje duże możliwości na stworzenie zakręconej hierarchii fixtures (zamiast modułów w kontenerach DI) i "wstrzykiwania" parametrów. Zaletą używania argumentów implicit i miksowania traitów nad używaniem kontenera DI jest to, że argumenty implicit i traity to podstawowe elementy języka i są w pełni wspierane przez IDE i kompilator. Elementy są wrzucane w konstruktory na etapie kompilacji (a więc kompilacja się sypnie jak nie będzie żadnego argumentu implicit w zasięgu do dobrania przez kompilator), a sam kod poddaje się dobrze statycznej analizie, więc mamy wszelkie udogodnienia od IDE jak nawigacja po kodzie (skąd się co bierze - IntelliJ pokazuje lokalizację argumentów implicit), itd
Wydaje mi się, że doskonale w ten sposób potwierdzasz moje stwierdzenie, że Java to podjęzyk. Może nie przyznajesz tego wprost, ale to potwierdzasz.
jarekr000000 napisał(a):
Dzięki za docenienie, staram się :-). Wiele z tego co się nauczyłem zawdzięczam innym ludziom, którzy robili taką niepotrzebną robotę - staram się to powoli odpracowywać (w końcu mam czas).
Tylko, że oni robili to w godzinach pracy. No, ale ok. Nie moja sprawa.
Nie wiem co to za bilblioteki automockujące - wpisałem sobie, żeby się temu przyjrzeć (biblioteki C# już nieraz mnie zaskoczyły pomysłami), ale może podasz pomocny konkret?
Chodzi mi konkretnie o to: https://github.com/AutoFixture/AutoFixture
Raz, że potrafi dostarczyć losowe (bądź nie) dane do testów, dwa że dostarcza działającą implementację testowanej klasy z wstrzykniętymi wszystkim zależnościami, które sobie sam wyciąga i tworzy. A jeśli zależności są interfejsami, to może użyć frameworka mockującego do automatycznego zamockowania tychże, przy czym zamockowane automatycznie metody będą zwracały domyślnie losowe dane. (Ale oczywiście można wstrzyknąć zwykłego mocka ze sztywnym wynikiem, jeśli tego potrzebujemy.)
Głównym problemem przy testowaniu jest aranżacja testów. Jeśli testowany kod korzysta z zależności od których wymaga
zwrócenia wyników, aby przejść dalej, zawiera jakąś ifologię, to w efekcie mimo, że chcemy przetestować najprostszą ścieżkę musimy najpierw napisać wiele linii konfigurujących mocki - tylko po to, żeby się nie wywaliły na jakimś NullExceptionie. Co więcej, jeśli zmienimy sobie sygnaturę naszej klasy, to testy nam się przestaną kompilować.
AutoFixture pozwala tego uniknąć czyniąc kod testowy znacznie przyjemniejszym w utrzymaniu.
Ogólnie to świetna rzecz - zarówno dla młodych projektów, jak i dla jakichś legacy testów, które można dzięki temu znacznie skrócić.
Tak, oczywiście lepszym rozwiązaniem jest mieć mniej zależności i ja się z tym już w tym wątku zgodziłem - tylko nie zawsze tak się da - zwykle im wyżej klasa leży w hierarchii, albo im bardziej jest na zewnątrz, tym tych zależności trudniej uniknąć.
Bo, w sumie jak są takie automoki cudowne - to ja w sumie zrobił bym tą jedną linijką Automoka i puścił na produkcję.
Jeśli nie przeszkadzają Ci losowe dane, to czemu nie?
Skoro jest na tyle dobry żeby zastąpić mockowaną klasę w testach - to powinien być też dobry na produkcję (albo raczej się nie rozumiemy - bo naprawdę nie wyobrażasz sobie co ludzie potrafią zamockować (niepotrzebnie)).
Być może nie... ja już wiele razy myślałem, że wszystko w życiu widziałem, zwykle po miesiącu w nowej pracy stwierdzałem, że nie miałem racji.
Np. ostatnio odkryłem, że ludzie potrafią zrobić interfejs dla DTO, bo potrzebują mocka w testach, a zwykłej implementacji nie mogą użyć, bo w konstruktorze czytają z konkretnego pliku. (Dobrze, że to programiści, a nie np. murarze, bo budując dom zapewne postawiliby pełen sześcian z cegieł, a potem wykuwali w nim pokoje.)
(Btw: w javie zaimplementowałem kiedyś mały serwisik na Mockach - ale to było po piwie, miałem też pomysł, żeby to pociągnąć dalej i testy dla odmiany zrobić na konkretnych klasach (ale skończyło mi się piwo)).
Ja kiedyś na mockach zaimplementowałem kontekst użytkownika - wiedziałem, że na razie będzie tylko jeden użytkownik, więc zwracałem na sztywno jego ID i nazwę, i mogłem przełożyć w czasie pracę nad właściwą implementacją.
Dodatkowym plusem było to, że było to 100% bezpieczne rozwiązanie. ;)
Trochę masz racji, ale ja uważam, że Java nie jet aż tak zła - jak złe jest jej "enerprisey" community. Goście utkwili w roku 2006 i nie potrafią się z niego wydostać...
A co gorsza zarazili tych od .NETa.