@jablan
Citat:
Kako onda znaš da ti funkcija radi ispravno? Static typing ti može garantovati da funkcija prima broj i vraća broj, ali ti ne garantuje da je broj tačan.
O da, moze, samo sto u slucaju type sistema to deluje glupo da radis, ali u slucaju unit testova to je sasvim OK.
Ja bi mogao bez problema da definisem tip, koji ce biti nesto ovako:
edit: Zaboravio sam da stavim link od wikipedia-e, gde se demonstritra unit test
https://en.wikipedia.org/wiki/Unit_testing, posto je primer vezan za to.
Code:
class AdderResult : int
{
AddedResult(int value)
{
if (!(value == 1 || value == 2 || value == 3 || value == 4 || value == 2222))
throw new ArgumentException("Invalid value");
}
}
class AdderImpl implements Adder {bbbbbbg
public AdderResult add(int a, int b) {
return new AdderResult(a + b);
}
}
I eto, type sistem garantuje da je uvek vracen rezultat koji je definisan u specifikaciji. Ali ocigledno je da je intent da hoces da testiras funkciju sabiranja, i onda je ocito da su sve vrednosti integera zadovoljene, tako da je ovaj primer sa wikipedia-e malo los za demonstraciju ovoga ali i samog unit testa.
Ono gde unit testovi imaju prednost je "snapshot specifikacije", tj. ti imas odredjenu verziju unit testova koja moze biti "out of sync" sa trenutnom implementacijom i tu mozes uhvatiti greske. Tipa imas funkciju da ti vrati, recimo, neki hash, i hoces da jednom kada je razvijes za istu ulaznu vrednost svaki put da dobijes istu izlaznu vrednost, ali recimo krenes nesto vremenom da optimizujes i negde u nekoj hierarhiji promenis code i namestis bug. Unit testovi ti ovo mogu validirati (mada moze i ova smesna konstrukcija gore ali tek u runtime) ali generalno ja nikad nisam imao potrebu za tim, type sistem vec i ovako mi proverava gomilu stvari u svim slucajevima. Ono oko cega dolazi zbun je upravo promena code-a, jednom kada promenis code, promenio si specifikaciju. U sustini ovo meni nikad nije bilo problem i obican smoke test otkriva vecinu stvari ako ga type sistem propusti... no cak i da cepidlacimo, zasto pobogu da radim rucno testove (a da, ja ih ne pisem u opste :)), ali hocu reci, ako neko zaista razume svrhu testova, onda bi trebalo da je skroz za full type system support i automatsko testiranje (ne znam iskreno kakvo je stanje danas kada je u pitanju automatika ali MS je imao u planu tool koji upravo radi to, tamo negde oko 2008, bili su odlicni videi, tool je najavljivan na veliko, ali u sustini to niko nije razumeo, tako da se ostalo na rucnom kucanju).
I na kraju dodjemo do onog sto je mmix rekao, gomile resursa ulozeno u to da se temeljno pisu programi i na to su skripteri pljunuli u lice svim PhD-ovima, inzinjerima i svim ostalima koji su ulozili svoj trud u razvoj raznih alata kako bi programiranje svima bilo lakse i manje kostalo... ali najgore od svega je, sto je recimo neko poput MS popustio (google je davno skontao foru, pa je uglavnom bio u fazonu samo daj community-u a para neka se valja :))
Ja recimo nisam ni dotakao temu alata, to je posebna prica. Bez type sistema ne mozes praviti kvalitetan alat (tj. mozes ali onda radis upravo ono sto ti pruza type sistem na mnogo rudimentarnijem nivou :))
[Ovu poruku je menjao negyxo dana 28.07.2017. u 21:00 GMT+1]