On Tuesday, 23 July 2013 09:26:06 UTC+2, Andrzej Jarzabek wrote:
> On 23/07/2013 07:13, Adam Klobukowski wrote:
>
> > On Tuesday, 23 July 2013 02:16:02 UTC+2, Andrzej Jarzabek wrote:
> >
> > Yhm. Dla takiego trywialnego przypadku jest to proste.
>
> Przykład był trywialny żeeby sensownie zilustrować tezę.
>
> > Wyobraź sobie
> > że masz obliczenia gdzie możesz mieć sporo danych wejściowych, ok. 60
> > parametrów konfiguracyjnych obliczeń a klient zwraca uwagę na 12
> > cyfrę po przecinku. Udokumentować to możesz, ale ta dokumentacja nie
> > sprawdzi Ci poprawności obliczeń dla wszystkich przypadków. Unit
> > testy, jak są dobrze napisane, maja taką szansę.
>
> Owszem, ale też zasygnalizują ci, że funkcja z 60 parametrami czy klasa
> z 60 setterami to prawdopodobnie nienajlepszy pomysł i powinieneś rozbić
> problem na składowe zagadnienia, które będą realizowane przez osobne
> jednostki kodu (funkcje, klasy), które będą miały swoje unit testy,
> przez co nie ma potrzeby sprawdzania testami kombinacji warunków
> brzegowych itp. dla 60 parametrów.

Podzielone to owszem jest, testy też, ale i tak istotne jest to co jest finalnie na
wyjściu. Po prostu unit testy nie dają gwarancji że jeśli każde 10% ze 100% działa
ok, to całe 100% będzie działać ok.

AdamK