[Verbatino]

@Verbatino: Code Coverage. Ostatnimi czasy odnoszę wrażenie, że cały zagraniczny rynek jara się tym wskaźnikiem wziętym z tyłka.
Ktoś kiedyś chyba sprzedał managementowi historyjkę, że stopień otestowania kodu danej applikacji jest kluczowy...przy czym nie dodał, że w banalny sposób programista może wygenerować zestawy w taki sposób, że wskaźnik będzie wynosił 100%.
Nie będę ukrywał, że sam tego klientom nie mówię:P
Tylko jaki sens ma premiowanie lokalnych zespołów programistycznych na bazie tego wskaźnika?

#programowanie w #java #csharp #dotnet #ruby #rubyonrails #php #js trochę #webdev i #frontend

[filip_k]

#wincyjtagow

[npsr]

@Verbatino: premiowanie? Nie wiem, ale sprawdzanie pokrycia to chyba jednak przydatna sprawa...

[Verbatino]

@filip_k: Będę pamiętał o twojej radzie ( ͡° ͜ʖ ͡°)
@npsr: Nikt nie twierdzi, że mierzenie stopnia otestowania kodu jest nieprzydatne...
Tu chodzi o fakt, że firmy tworzą KPI sukcesu projektu bazując na code coverage... szczególnie w branży finance...

[npsr]

@Verbatino: No to trochę głupie. Rozumiem założenie, że np. Chcemy utrzymać pewien próg pokrycia, ale to tylko jeden z wielu wskaźników. BTW również ten sektor here

[Verbatino]

@npsr: Największy fun jest podczas spotkań z cyklu PM... ( ͡° ͜ʖ ͡°)
Klienci (przedstawiciele klienta) rzucają hasłami, które przeczytali na wiki pod frazą SQA a jako wykonawca (przedstawiciel wykonawcy) odpowiadasz tymi samymi formułkami... no i najważniejszy jest RAPORT (oh sweet lord jezus!) gdzie ZAWSZE rozpisuje się te same pierdoły o wymaganiach, software design, metodyce agile, zarządzaniu kodem, code review, testach i magicznym code coverage... Tak jakby

[MacDada]

@Verbatino: Code coverage jest pewnym wskaźnikiem odnośnie kodu. Tylko tyle i aż tyle. Nie ma sensu rozpatrywać go w izolacji.

Piszę testy do swojego kodu. Wiem, że są one napisane sensownie. Patrzę na CC, bo pomaga mi wykrywać co pominąłem albo jak bardzo przyłożyłem się w dany fragment kodu.

[Verbatino]

@MacDada: Co nie zmienia faktu, że tworzenie KPI na bazie CC jest IMHO głupotą do ² ( ͡° ͜ʖ ͡°)

[m.....t]

@Verbatino no bo ci ludzie oceniają ryzyko chociażby. Muszą mieć jakiś obiektywny wskaźnik. A to że te wskaźniki nie są poprawnie dobrane to się przeważnie ludzie orientują zbyt późno

[b0lec]

@Verbatino: no to jeżeli biznesowi tak bardzo zależy na raportach i wskaźnikach to oprócz testów powinna się liczyć jakaś inna metryka- na przykład wynik statycznej analizy kodu, ma to sens twoim zdaniem?
Dla mnie to i tak jest kosmos żeby komuś w firmie zależało na testach i jakości kodu (pracuję w firmie gdzie delikatnie mówiąc jest #!$%@?)

[WhirPool]

@Verbatino: Muszą mieć jakiś wskaźnik na którym mogą opierać się. Z CC trzeba zachować zdrowy rozsądek - nie można przesadzić ani w jedną, ani w drugą stronę. Jak firma przykłada uwagę do testów to bardzo dobrze o niej świadczy, ale nie powinno to wpływać na czytelność kodu lub łatwość jego pisania. Mówię tu np. o wzorcu MVP w którym mamy do wyboru Passive View (lepsza testowalność, ale dużo więcej kodu) lub

[Verbatino]

@b0lec: Nie bardzo rozumiem co rozumiesz przez statyczną analizę kodu - zautomatyzowane scannery czy code review?
Jeśli chodzi o scannery takie jak PMD to absolutnie jego wynik nie może być jakimś "miernikiem" gdyż wypluje on potencjalne zagrożenia, które mogą być już w jakiś sposób obsługiwane albo zaleci przemodelowanie funkcji/metody na sposób "ustandaryzowany" wg niego. Wytłumacz to potem klientowi, że scanner nie jest doskonały gdzie klient zazwyczaj ma problem z zaprogramowaniem pilota

[Verbatino]

@WhirPool: Architektura akurat nie ma tu żadnego znaczenia IMHO.
Czy to MVC, czy MVVM, czy MVP, czy PAC, czy cokolwiek innego byśmy nie robili...Jak ludziom będzie zależało na premii z 6 mc. kontraktu to dorobią te testy po łebkach by było 100% na mierniczku...

Oczywiście ja zgadzam się z Tobą, że biznes musi mieć jakiś miernik... ale CC to dla mnie głupota...

[phosphor-bronze]

@Verbatino: To jest tak, jak kiedyś było z mierzeniem ile LOC/h może wyciągnąć dany programista i ocenianie po tym jego wydajności. Nietechniczni managerowie zawsze potrzebują jakiegoś fetyszu, ułudy, że mają jakąś wiedzę i władzę nad techniczną stroną tworzenia oprogramowania. Co do samego coverage - zaczęliśmy pomiary dopiero wtedy, jak jeden potencjalny inwestor wycofał się z dealu, bo za mało miał statystyk...

Pamiętać trzeba, że kod kodowi nierówny i brak pokrycia kluczowych

[Verbatino]

@phosphor-bronze: Z tym testowaniem mutacyjnym rzeczywiście pomysł dobry by na jego podstawie miernikować efekty pracy. Osobiście nigdy tego nie robiłem, ale zakładam, że w ramach sprintów ciężko będzie w 100% przemielić wszystkie możliwości. Troszkę problematyczne...

[Verbatino]

@phosphor-bronze: W związku z sugestią dot. testowania mutacyjnego dobiłem się do załączonego filmiku...
Co ciekawe w ok. 36:30-37:30 prelegent Marcin Zajączkowski doszedł do tego samego wniosku o którym jest mowa w tym wątku ( ͡° ͜ʖ ͡°)

[phosphor-bronze]

@Verbatino: zgadzam się. Ciężko zrobić testy mutacyjne częścią CI, bo zajmą masę czasu przy dużym projekcie. Przy krótkich projektach w ogóle może nie być czasu, żeby się w to bawić. Sensowne natomiast wydaje się wykorzystywanie ich w charakterze diagnostycznym, np. przejmujesz projekt i chcesz zobaczyć ile warty jest deklarowany coverage. Wtedy też często wychodzą braki teamu w zakresie TDD.

[Ragnarokk]

@Verbatino:
Wymaganie 100% pokrycia kodu testami to IMO patologia. Oddam głos Martinowi Fowlerowi

Like most aspects of programming, testing requires thoughtfulness. TDD is a very useful, but certainly not sufficient, tool to help you get good tests. If you are testing thoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s. I would be suspicious of anything like 100% - it would smell of someone writing