Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

tu co nieco o get/set z ust programisty....

http://sprawnainzynieriaoprogramowania.blogspot.com/20...

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Paweł Włodarski:

Michał Z.:

Paweł Włodarski:

[...]

Nie chodzi o to aby zmienić typ zwracanego obiektu ale aby nie było tego gettera. Luknij na necie frazę "tell don't ask".

Dalej nie widzę różnicy. Poważnie. Co za różnica, czy zrobię get, żeby pobrać stan, nawet jak to przełoży się na message, i potem coś tam nadziergam... No, albo nie będę miał tego gettera?

[...]

A innym przypadku sama komórka może być odpowiedzialna za zarządzanie swoim stanem , wtedy po po prostu jej mówisz aby to zrobiła.

Jestem programistą - zacząłem jeszcze w ubiegłym stuleciu. Rozumiem o czym mowa. Poważnie. Rozumiem dlaczego udostępnianie informacji na zewnątrz klasy, przetwarzanie tam - to może być problem. Chodzi o to, że jak jest Hibernate / JPA, do tego DTO - to będą klasy używane jako kontenery do przechowywania danych. W tym przypadku - albo będzie get/set - albo będzie bezpośrednie grzebanie po polach. Dlaczego? Bo logika biznesowa jest w innej warstwie. Ja wiem, że można opakować, że nie powinno się wielu rzeczy robić, że są z tego problemy i tak dalej. Tyle, że jest jak jest. I kompletnie nie widzę sposobu rezygnacji z klas, które reprezentują rekord w bazie i służą tylko do trzymania danych. Wniosek jest taki, że albo będziemy grzebać po polach palcem, albo przez metody. Wolę palcem bezpośrednio, ale jak ktoś woli get/set - też nie widzę problemu. Bywa z tym masa problemów, np. taki Hibernate w cache trzyma kopię obiektu, żeby wiedzieć kiedy się zmienił... Z drugiej strony - klasy przetwarzające mogą być kompletnie bezstanowe. Co też ma swoje pozytywy...

Co innego, jak w podobny sposób zacznie się zachowywać komponent. Jak go używamy i jest w stanie "failed" to coś tam, coś tam. To łamanie podstawowych zasad... "violators will be shot, survivors will be shot again". No, ale skoro kontener jest bezstanowy, można spać spokojnie. :) Coś za coś.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jarek Żeliński:
tu co nieco o get/set z ust programisty....

http://sprawnainzynieriaoprogramowania.blogspot.com/20...

Cytuję: "Nie używaj klas o więcej niż dwóch polach". W systemie, który robię są dedykowane rozwiązania do obsługi wyjątków - żeby były lokalizowane, audytowane itp. Do tego logowanie, potrzebuję też użyć DAO. Czasem wypada użyć jeszcze jednego serwisu - żeby np. przewalutować... W myśl tego bloga - połowę z tego mam inicjować - per wywołanie metody? Imię, nazwisko, a gdzie klucz? :D

Dobra - czepiam się, bo gość z miejsca zaznaczył, że to ekstremalna obiektowość. Uważam, że takie ćwiczenia, co on tam napisał - warto robić. Stosowanie sztywno tych zasad, w codziennym programowaniu? Powiem tak - coś za coś. Albo duże klasy, albo dużo klas. Dla mnie - w żadną stronę nie ma co przeginać.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:20

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Michał Z.:
W tym przypadku - albo będzie get/set - albo będzie bezpośrednie grzebanie po polach. Dlaczego? Bo logika biznesowa jest w innej warstwie.

i tu (pogrubienie) widzę kluczowy ... dlaczego "w innej warstwie", ortodoksyjne podziały na warstwy szkodzą (to chyba właśnie dziedzictwo EJB) , polegające na opakowaniu "obiektowością" funkcyjnego projektowania i programowania.

Nie wildze problemu by dziedzina biznesowa (obiekty zawierające i wartości i logikę ich przetwarzania) stanowiła jeden spójny komponent zwany zgrabnie w MVC: Domain Model. Słusznie Paweł zauważył, że w takim modelu od klas żądamy działania a nie danych.

nie ma przymusu stosowania osobno "klas przechowujących dane" i "klas przechowujacych logikę" to to nic innego jak funkcyjne programy z talk 80-tych (bez ironii), wiem także że wiele fim nadal ma taki 'styl programowania" ale to już problem tych firm.

Da się inaczej i np. DDD jest tego doskonałym przykładem.

Ja wiem, że można opakować, że nie powinno się wielu rzeczy robić, że są z tego problemy i tak dalej. Tyle, że jest jak jest. I kompletnie nie widzę sposobu rezygnacji z klas, które reprezentują rekord w bazie i służą tylko do trzymania danych.

a ja widzę i da się... w projektach, jako projektant części domenowej, nie schodzę poniżej Repozytorium, w ogóle nie operuje pojęciem "rekord bazy danych" bo baza danych to "jakaś implementacja repozytorium" i to jest poza mną, to implementacja czyli jak dla mnie robota dopiero developera.

Wniosek jest taki, że albo będziemy grzebać po polach palcem, albo przez metody. Wolę palcem bezpośrednio, ale jak ktoś woli get/set - też nie widzę problemu. Bywa z tym masa problemów, np. taki Hibernate w cache trzyma kopię obiektu, żeby wiedzieć kiedy się zmienił... Z drugiej strony - klasy przetwarzające mogą być kompletnie bezstanowe. Co też ma swoje pozytywy...

Co innego, jak w podobny sposób zacznie się zachowywać komponent. Jak go używamy i jest w stanie "failed" to coś tam, coś tam. To łamanie podstawowych zasad... "violators will be shot, survivors will be shot again". No, ale skoro kontener jest bezstanowy, można spać spokojnie. :) Coś za coś.

powyżej sam sobie odpowiedziałeś dlaczego to podejście jest złe, pytanie: dlaczego klasa ma być inaczej traktowana niż komponent skoro oba te "byty" mają interfejs a "złożoność jego implementacji" nie powinna determinować podejścia...

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Michał Z.:
Uważam, że takie ćwiczenia, co on tam napisał - warto robić.

tez tak uważam i robię je często :) uczą dwóch rzeczy: pokory i zrozumienia rozwiązywanego problemu

Stosowanie sztywno tych zasad, w codziennym programowaniu? Powiem tak - coś za coś. Albo duże klasy, albo dużo klas. Dla mnie - w żadną stronę nie ma co przeginać.

teraz coś zupełnie subiektywnego ode mnie: jeżeli oporem przeciwko "dużo klas" ma być oszczędność pracy programisty to "już go nie lubię" w projekcie, bo uproszczenia modeli dziedzinowych to kluczowy powód późniejszych lawinowych kosztownych przeróbek przy zmianach wymagań a nie raz nawet blokady na ich wprowadzanie.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Wtedy nie było by problemu ale na tej zasadzie, że nie było by programu.
Jak bez znajomości stanu (BTW: kto napisał wrapera na typ boolean ?) komórki można napisać "grę w życie" ?

Poszukaj na necie przykładów z coderetreat.

Ale to publikowali ludzie którzy najpierw kazą implementować "grę w życie" a następnie przerabiać ją na "szachy" a kiedy to się nie udaje, twierdzą (podobno), że "właśnie dlatego gettery są złe" ;)

Ale to wiesz czy zgadujesz?

Tyko podejrzewałem - ale poczytałem trochę co się tam dzieje; z szachami spudłowałem ale byłem blisko; przynajmniej w 'mojej osobistej metryce absurdu'.

http://css.dzone.com/articles/lessons-learned-code-ret...

I też nie jestem pewien, czy z tym pudłem jest lepiej czy gorzej dla "modus operandi" coderetreat. Czy wolałbyś przerobić "game of life" na szachy czy uczyć się programować bez użycia słowa kluczowego "return", albo "bez getterów" albo napisać "game of life" ale dla trzech stanów komórki ? Ja bym wolał te szachy.

To nie jest rozwijające, to jest po prostu głupie.

Jakieś matołki coś organizują (sprawdź, jak doskonałymi programistami byli prowadzący ten event) coś pierniczą od rzeczy przez długi czas (np: dobry programista zna skróty klawiszowe, i nie używa "return") a później, ludzie bez poczucia humoru, twierdzą, że "gettery są złe" ...

Wydaje mi się, że powinienneś nabrać trochę dystansu do siebie bo czasami piszesz jakbyś pozjadał wszystkie rozumy.

Damn, now You now that I ate all minds with some fava beans and a nice chianti... ;)
Dobry argument; zapamiętam. Co trzeba zjeść, żeby wiedzieć, kto pozjadał wszystkie rozumy ? :D

Naprawdę poczytaj o co chodzi w tym ćwiczeniu bo "gra życie" nie jest tam celem tylko narzędziem.

Narzędziem do udowodnienia, że getter boola z klasy wrapującej stan dla gry "game of life" zupełnie nie sprawdza się w jakiejś innej grze gdzie domena wartości komórki nie jest "true" / "false".

Wniosek - gettery są złe.

Przepraszam,że musiałem do ciebie napisać bezpośrednio ale już nie wiem jakie apele na to twoje trolowanie zastosować.

Proste - nie pisz :) ... o tych getterach; za późno ;)Jakub Wojt edytował(a) ten post dnia 13.12.12 o godzinie 23:47

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Doskonale rozumiem tą zasadę, ale obawiam się, że sędzia na argument "i tak by umarł" najwyżej zaostrzył by karę ;)

to zależy od tego czy mowa o staruszku i eutanazji czy o dobrze uczącym się zdrowym dziecku...;)

Hm..
Podoba mi się koncepcja żeby ewentualna zmiana wymagań pociągała za sobą konieczność, jak w przypadku "eutanazji", dostarczenia kilograma dokumentacji, wydania dużej ilości gotówki i wyrzucenia kogoś z obiegu realizacji projektu.

Ciekawe czy wtedy, "zmiany wymagań" były by "nieuniknione" ...

Można też zastosować reverse trolling tzn. od strony programisty: "_Musicie_ zmienić wymagania, ok; my _musimy_ napisać kolejny entity framework". Jakub Wojt edytował(a) ten post dnia 13.12.12 o godzinie 22:09

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:21

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jakub Wojt:

Doskonale rozumiem tą zasadę, ale obawiam się, że sędzia na argument "i tak by umarł" najwyżej zaostrzył by karę ;)

to zależy od tego czy mowa o staruszku i eutanazji czy o dobrze uczącym się zdrowym dziecku...;)

Hm..
Podoba mi się koncepcja żeby ewentualna zmiana wymagań pociągała za sobą konieczność, jak w przypadku "eutanazji", dostarczenia kilograma dokumentacji, wydania dużej ilości gotówki i wyrzucenia kogoś z obiegu realizacji projektu.

nie zrozumiałem i nie wiem czy to do mnie, osobiście hołduję tezie, że w dobrym projekcie nie ma pojęcia zmiany (wymiany) wymagań są co najwyżej zmiany zakresu projektu. Jak mam przed sobą dobry model człowieka to żaden projekt nie może wymagać np. dodania czy ujęcia kończyny... można, przy małym budżecie, dywagować czy bardziej marzną mi dłonie i kupić tylko rękawiczki czy może uszy i kupić tylko czapkę.

W moich oczach, projekty programistyczne wymagające "wymiany" kodu (poza refaktoryzacją :)) to złe projekty i tyle..

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jarek Żeliński:

Cezary Kowalski:

wydaje mi się, że system składający się 500 klas nie wymaga napisania 500 testów a jedynie kilkunastu...

Tak i nie - wszystko zależy od poziomu ryzyka liczonego w $$$ i/lub ludzkim życiu.

Ma tu na myśli sytuacje:
- komponent i jego interfejs: tylko test interfejsu (jeżeli jest złoóżnoy, testy interfejsów jego podsystemów)
- agregat: testy korzenia agregatu (zakładam, że wnętrze agregatu jest chronione, jego korzeń jest jego interfejsem)

Jeżeli dobrze zrozumiałem, co chciałeś powiedzieć to masz rację. Powiedzmy, że mamy klasy A,B,C przy czym klasa C jest agregatem klas A i B. W takiej sytuacji faktycznie nie ma sensu testować klas A i B jako składowe klasy C ale tylko pod warunkiem, że klasy te są rzeczywiście hermetyczne i wcześniej przetestowane. Natomiast należy zwrócić uwagę, że agregat sam w sobie może zawierać i/lub udostępniać nową funkcjonalność i ta już powinna być testowana. Nawet jeżeli agregat nie udostępnia i/lub zawiera takiej funkcjonalności to powinna być przynajmniej utworzona klasa testowa aby w przyszłości jak zajdzie potrzeba zmian w klasie C nie było wymówki "nie było przewidzianej klasy testowej to nie pisałem przypadków bo myślałem, że nie trzeba".

W idealnym przypadku klas testujących (jednostkowych) powinno być tyle ile klas w systemie. Ilość przypadków testowych jest funkcją ilości metod (nie tylko tych wchodzących w skład interfejsów ale też tych prywatnych) oraz charakteru domeny. Ilość scenariuszy powinna być przynajmniej równoważna ilości prawidłowych przypadków użycia. Proszę zwrócić uwagę, że jeszcze nie ma na liście testów integracyjnych a już widać, że "testów" jest więcej niż samych klas a przynajmniej więcej niż interfejsów.

Natomiast w praktyce wygląda to tak, że scenariusze testowe pokrywają tylko najpopularniejsze i/lub krytyczne przypadki użycia, co jeszcze daje się przełknąć. Natomiast wyłączanie z testowania klas, które w chwili pisania na oko można sprawdzić, że są dobre i/lub przy tym ważne z perspektywy prawidłowego działania systemu powinno być karane "biczowaniem na środku rynku". Dlaczego? Ponieważ jak za rok, dwa, pięć przyjdzie zmiana do systemu, która wymaga zmiany w tej "prostej" klasie i system się wysypie na produkcji (nie mógł wysypać się wcześniej bo klasa nie była testowana) i przy tym ktoś pójdzie do piachu albo firma straci kupę szmalu to wywalą albo wsadzą za kraty nie projektanta, nie kierownika, nie dyrektora tylko programistę, który dokonał zmiany.

I tu wracamy (po nudnym wywodzie - sory) do prostego wniosku, że zakres testów jest pochodną ryzyka liczonego w $$$ i/lub ludzkim życiu. Dla pierdletu klas i przypadków może nawet być zero i wszystko "w boju"ale dla firmware działającego na aparacie do pomiaru ciśnienia i tętna będzie sprawdzane nawet położenie przecinka na wyświetlaczu aby czasem ze 130,0 nie zrobiło się 1300 mmHg.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Natomiast należy zwrócić uwagę, że agregat sam w sobie może zawierać i/lub udostępniać nową funkcjonalność i ta już powinna być testowana. Nawet jeżeli agregat nie udostępnia i/lub zawiera takiej funkcjonalności to powinna być przynajmniej utworzona klasa testowa aby w przyszłości jak zajdzie potrzeba zmian w klasie C nie było wymówki "nie było przewidzianej klasy testowej to nie pisałem przypadków bo myślałem, że nie trzeba".

racja, czy tu nie należy założyć, że test interfejsu takiego agregatu (klasy będącej korzeniem) testuje wszystkie jego operacje?

W idealnym przypadku klas testujących (jednostkowych) powinno być tyle ile klas w systemie.

i tego chyba nie rozumiem, jeżeli wykonam jazdę testową samochodem (dobrana trasa, prędkości, minimlany czas trwania itp..) to chyba znaczy że "samochód jest dobry" a samochód to agregat... po co mam dodatkowo odrębnie testować sam silnik czy radio.... chyba, że mowa o kolejności, że dostawca silników testuje silnik na hamowni przed wysłaniem do fabryki samochodów itp....

Ilość przypadków testowych jest funkcją ilości metod (nie tylko tych wchodzących w skład interfejsów ale też tych prywatnych) oraz charakteru domeny.

zakładam, że metody prywatne są wykonywane przy okazji użycia metod publicznych, bo po co by były...

Ilość scenariuszy powinna być przynajmniej równoważna ilości prawidłowych przypadków użycia.

z tym zgoda w 100%, ja zakładam testowanie przypadków bo projektuję tak, że każdy przypadek ma swoja klasę (staram sie używać MVCMVVM), która go obsługuje, reszta dziedziny pracuje na te przypadki użycia, dlatego do tej pory zakładałem, że przetestowanie każdego przypadku użycia daje 100% pokrycie testami

Natomiast w praktyce wygląda to tak, że scenariusze testowe pokrywają tylko najpopularniejsze i/lub krytyczne przypadki użycia, co jeszcze daje się przełknąć.

patrz wyżej

zakres testów jest pochodną ryzyka liczonego w $$$ i/lub ludzkim życiu.

oczywiście :)

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

to zależy od tego czy mowa o staruszku i eutanazji czy o dobrze uczącym się zdrowym dziecku...;)

Hm..
Podoba mi się koncepcja żeby ewentualna zmiana wymagań pociągała za sobą konieczność, jak w przypadku "eutanazji", dostarczenia kilograma dokumentacji, wydania dużej ilości gotówki i wyrzucenia kogoś z obiegu realizacji projektu.

nie zrozumiałem i nie wiem czy to do mnie, osobiście hołduję tezie, że w dobrym projekcie nie ma pojęcia zmiany (wymiany)

Uf, Rozumiemy się; znowu miałem to dziwne uczucie, że rozmawiamy o dwóch rożnych rzeczach ;)

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Ale to wiesz czy zgadujesz?

Tyko podejrzewałem - ale poczytałem trochę co się tam dzieje; z szachami spudłowałem ale byłem blisko; przynajmniej w 'mojej osobistej metryce absurdu'.

Plus jest taki, że tym razem przynajmniej coś przeczytałeś

Czytania głupot pisanych przez ludzi, których przepisem na "umiejętności programistyczne" jest pisane metod bez "return / gettów", wolałbym unikać.

Jeśli czytasz matołków i bierzesz ich pisaninę na serio to zaczynasz myśleć tak jak oni;

kurcze, znasz
1. Agile - "metodykę realizacji projektów IT",
2. TDD (najprawdopodobniej) - "metodykę weryfikacji wymagań w projekcie IT"

a masz problem z najprostszym mechanizmem OO - getteremi ...

Czytaj sobie te "mądrości" dalej :)Jakub Wojt edytował(a) ten post dnia 15.12.12 o godzinie 21:15

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:21

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:21

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Paweł Włodarski:

Jakub Wojt:

[Próba merytorycznego ratunku dyskusji]

Miałeś w trakcie tej dyskusji dwa posty gdzie próbowałeś napisać coś konstruktywnego - nie na zasadzie "jesteś głupi" ale "uważam, że moje rozwiazanie jest madre bo ..."

Możemy jeszcze podjać jedną próbę dykusji na temat bez obrażania siebie nawzajem.
Spróbojmy z tym samochodem skoro z grą życie nie wyszło.

Pierwsza próbka kodu :

car.getEngine().start();

Druga próbka kodu:

car.start();

Według mnie w przypadku pierwszym gdy zmieni się interfejs klasy Engine
zmiana dotknie zarówno klas Engine,Car jak i każde miejsce gdzie getter został użyty.
W przypadku bez użycia gettera ograniczamy zmiany jedynie do klas Engine i Car.

A jaka jest twoja opinia?

Przepraszam, że się wtrącam ale limit tolerancji został wyczerpany powyższym przykładem i stwierdzeniem pod nim. Moja opinia Młody Kolego jest taka, że Jakub wcale cię nie obraża tylko ochoczo i asertywnie reaguje na opowiadanie głupot, których po części jesteś autorem a po części klepiesz po innych bez zastanowienia.

1) Przytoczony kod funkcjonalnie i semantycznie nie jest równoważny.

Względnie poprawnie powinno być (i to też tylko przy założeniu, że otrzymanie silnika gotowego do odpalenia nie wymaga szeregu innych czynności, co oczywiście jest nieprawdą):

car.getEngine().start();

car.engine.start();

2) Zmiana w interfejsie (czy są gettery / settery czy ich nie ma) pociąga za sobą zmianę zawsze i wszędzie gdzie zmieniony fragment był używany.

3) Przy dobrze zaprojektowanych interfejsach zmiany w nich wprowadza się sporadycznie a czasem wcale.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jarek Żeliński:

Natomiast należy zwrócić uwagę, że agregat sam w sobie może zawierać i/lub udostępniać nową funkcjonalność i ta już powinna być testowana. Nawet jeżeli agregat nie udostępnia i/lub zawiera takiej funkcjonalności to powinna być przynajmniej utworzona klasa testowa aby w przyszłości jak zajdzie potrzeba zmian w klasie C nie było wymówki "nie było przewidzianej klasy testowej to nie pisałem przypadków bo myślałem, że nie trzeba".

racja, czy tu nie należy założyć, że test interfejsu takiego agregatu (klasy będącej korzeniem) testuje wszystkie jego operacje?

Jeżeli masz na myśli pojęcie interfejsu takim jakie jest ono np.: w Java czy C# to wręcz trzeba. Ja miałem na myśli ciutkę szersze pojęcie, które może przedstawię na przykładzie:

public interface Driveable{



void turnLeft();



}



public class Car implements Driveable{



void turnLeft(){}

public float getOilPressure(){}



}



public class Motorcycle implements Driveable{



void turnLeft(){}

public Kicker getKicker(){}



}

Z mojej perspektywy metody getKicker i getOilPressure to też interfejs ponieważ metody są publicznie dostępne a nie zawsze daje się je sensownie zgrupować pod jednym typem abstrakcyjnym. Ale tak masz rację. Im więcej szeroko wykorzystywanych interfejsów tym mniej pisania klas i przypadków testowych oraz przetestowanie interfejsu gwarantuje przetestowanie klasy go implementującej ale tylko w zakresie tego interfejsu (typów przyjmowanych i zwracanych). A co z wartościami? Zobacz proszę na taki przykład:

public interface Drawable{



public int [] draw();



}



public class Square implements Drawable{



public int [] draw(){}



}



public class Triangle implements Drawable{



public int [] draw(){}



}



Drawable t = new Triangle();

Drawable s = new Square();



t.draw();

s.draw();

Wszystko niby identyczne ale na wyjściu pojawi się inny zestaw danych, którego poprawność też musi być sprawdzana.

W idealnym przypadku klas testujących (jednostkowych) powinno być tyle ile klas w systemie.

i tego chyba nie rozumiem, jeżeli wykonam jazdę testową samochodem (dobrana trasa, prędkości, minimlany czas trwania itp..) to chyba znaczy że "samochód jest dobry" a samochód to agregat... po co mam dodatkowo odrębnie testować sam silnik czy radio.... chyba, że mowa o kolejności, że dostawca silników testuje silnik na hamowni przed wysłaniem do fabryki samochodów itp....

Dokładnie tak (jeśli ufamy kontroli jakości dostawcy) plus czasem warto sprawdzić na wyrywki producenta, że by nie było akcji nawrotowej Toyoty :)

Ilość przypadków testowych jest funkcją ilości metod (nie tylko tych wchodzących w skład interfejsów ale też tych prywatnych) oraz charakteru domeny.

zakładam, że metody prywatne są wykonywane przy okazji użycia metod publicznych, bo po co by były...

Proszę o wybaczenie ale mam zwyczajnie skrzywiony punkt widzenia ponieważ widziałem jak ludzie rwali sobie włosy z głów bo babole prima ballerin (specjalistów nie do ruszenia w firmie) wychodziły dopiero w metodach publicznych a to powodowało straszne opóźnienia w projektach za które oczywiście dostawał kto inny po uszach. W skrajnych trzech przypadkach człowieka zwolniono a prima ballerina dostała premię :/

Ilość scenariuszy powinna być przynajmniej równoważna ilości prawidłowych przypadków użycia.

z tym zgoda w 100%, ja zakładam testowanie przypadków bo projektuję tak, że każdy przypadek ma swoja klasę (staram sie używać MVCMVVM), która go obsługuje, reszta dziedziny pracuje na te przypadki użycia, dlatego do tej pory zakładałem, że przetestowanie każdego przypadku użycia daje 100% pokrycie testami

Natomiast w praktyce wygląda to tak, że scenariusze testowe pokrywają tylko najpopularniejsze i/lub krytyczne przypadki użycia, co jeszcze daje się przełknąć.

patrz wyżej

Teraz całkowicie rozumiem twój punkt widzenia.

zakres testów jest pochodną ryzyka liczonego w $$$ i/lub ludzkim życiu.

oczywiście :)Cezary Kowalski edytował(a) ten post dnia 17.12.12 o godzinie 04:12

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jarek Żeliński:

Michał Z.:
Uważam, że takie ćwiczenia, co on tam napisał - warto robić.

tez tak uważam i robię je często :) uczą dwóch rzeczy: pokory i zrozumienia rozwiązywanego problemu

Stosowanie sztywno tych zasad, w codziennym programowaniu? Powiem tak - coś za coś. Albo duże klasy, albo dużo klas. Dla mnie - w żadną stronę nie ma co przeginać.

teraz coś zupełnie subiektywnego ode mnie: jeżeli oporem przeciwko "dużo klas" ma być oszczędność pracy programisty to "już go nie lubię" w projekcie, bo uproszczenia modeli dziedzinowych to kluczowy powód późniejszych lawinowych kosztownych przeróbek przy zmianach wymagań a nie raz nawet blokady na ich wprowadzanie.

Wcale nie takie subiektywne. Znam przypadek gdzie zarząd był zdecydowany na likwidację developmentu i zakup gotowego oprogramowania z odpowiednim wsparciem bo problem urósł do takich rozmiarów, że każde zadanie stanowiło wyzwanie (delikatnie mówiąc).

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Cezary Kowalski:
Wcale nie takie subiektywne. Znam przypadek gdzie zarząd był zdecydowany na likwidację developmentu i zakup gotowego oprogramowania z odpowiednim wsparciem bo problem urósł do takich rozmiarów, że każde zadanie stanowiło wyzwanie (delikatnie mówiąc).

prawdę mówiąc, spotykałem się nie raz z tezą, że w przypadku "jednego własnego produktu" własny development rzadko kiedy ma sens... część firm broni swojego developmentu twierdząc, że to chroni ich know-how i tu ma rację, włąsny analiytyk projektant szybko ulega "degradacji" wiec w zasadzie optymalna sytuacja to:
- własny dedykowany produkt w obszarze budowania przewagi
- wynajęty doświadczony projetant (projekty obligatoryjnie pzrekazywane z prawami majątkowymi wyłącznymi)
- zewnętrzny wykonawca realizuje projekt (nie otrzymuje żadnych praw do realizacji projektu za wyjątkiem otrzymania egzemplarza projektu który ma powstać jako dzieło zależne.Jarek Żeliński edytował(a) ten post dnia 17.12.12 o godzinie 09:04