On Fri, 19 Jul 2013 00:05:48 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>wymagane, są podane jako przykład "dobrych" komentarzy. Jako zły rodzaj
>komentarza było pisanie kto napisał przy poszczególnych kawałkach kodu,
>przykład z książki "Added by Rick". No więc ja się zgadzam, że takie
>komentarze są bez sensu.
>

Mam watpliwosci. Kod jes twspolna wlasnoscia. Kazdy mzoe zrobic
zmiany. Jezeli zrobil zmiany, powinien te zmiany udokumentowac. KTO i
CO. Inaczej zrobi sie niekontrolowany burdel

>To, co przedstawiasz, to fałszywa alternatywa. Albo zatrudniasz
>fachowców i wtedy masz wybór między zatrudnianiem fachowców i
>testowaniem a zatrudnianiem fachowców i nie testowaniem,

To jest nonsens. WSZYSCY robia bledy, rowniez wysoko kwalifikowani
fachowcy.

>Jakie testy do testów? Do testów nie piszesz testów przecież.

Pisze sie testy do testow. Ja pisalem, na przyklad. Testy moga byc
calkiem skomplikowanymi procedurami. Musi byc pewnosc ze test jako
taki dziala prawidlowo. Z rdguly test polega na tym ze dla okreslonych
danych wejsciowych metoda musi generowac okreslone wyniki. Ale to czy
ustalilismy JAKIE wyniki sa prawidlowe? I czy jak ktos cos zmieni w
tescie, to przypadkiem nei spieprzy testu?

Przyklad - pewna metoda rozwiazuje "w srodku" zadanie metoda
Programowanie Liniowego. Tezt musi sparedzic czy dla okreslonych
danych wynik jest prawidlowy. Wiec tez musi rozwiazac zadanie
programowania liniowego, ale metoda "na skroty" - z pominieciem calej
zlozonosci testowanej metody. Czy to obliczanei "na skroty" ma sens?
Do tego potzrebny jest test

Oczywiscie, nikt nei robi tego w nieskonczonosc, ale test do testu to
czesto spotykana praktyka

Poza tym koncepcja ze "siada sie i pisze test a potem implementacje"
sprawdza sie tylko przy programowaniy "getters" i "setters".

> Co to jest
>w tym przypadku "moduł weryfikujący"? Testy jednostkowe (a także
>acceptance tests) są testowane w metoldach TDD ręcznie w bardzo prostu
>sposób - zaczynasz od pisania testu, jeśli test przechodzi, znaczy że
>jest źle napisany.

Ze co?...

>Następnie implementujesz to, co test testuje i
>regularnie zapuszczasz testy, jeśli testy przejdą zanim skończysz, to
>znaczy że test jest źle napisany. Jeśli skończysz, a test nie
>przechodzi, to dedukujesz tradycyjnymi metodami dlaczego i albo
>znajdujesz błąd w kodzie, albo w teście.
>

Przepraszam, ale to nei ma sensu. Wiem ze to jest napisane w
ksiazkach, ale to niczego nei dowodzi

>> Wszystko to zabiera czas i zasoby (ludzkie, nie komputera). A tych
>> zasobów jest ograniczona ilość.
>
>Oczywiście, ale konsekwencje braku unit testów (i innych testów
>automatycznych) często zabierają więcej czasu i zasobó niż pisanie tych
>testów.
>

W normalnych warunkach pzremyslowych czas projektu oblicza sie z
testami. Srednio 75% kodu pisanegp pzrez programiste to sa testy.

Jak u mnie, testy sa puszczane kazdej nocy pzrez specjalny zespol
zajmujacy sie testowaniem. Maja do tego dedykowany hardware i dosyc
skomplikowany software. Dodatkowo, kazdy programista musi puszczac
testy, i jak robi "check in" do systemu kontroli kodu (Subversion
konkretnie) to musi miec pewnosc ze jego testy pzrechodza. Jak nei
pzrechodza i wykryje to team testujacy, to programista dostaje
starszny opierdol

A.L.