birim testi ^*

• (bkz: junit)
• bir kaynak kod üzerinde yapılan test. daha cok sentaks semantik ve notation üzerine yoğunlaşmış kalite testi.
• ürünün iç yapısı incelenerek işlevlerin spesifikasyonları sağladığı, dahili komponentlerin faal olduğu görülür.
• genelde integration asamasi oncesinde bitirilir, sonra integration test'lere gecilir. otomatize edilmelidir.
• (bkz: http://en.wikipedia.org/wiki/unit_testing)
• guzel platformumuz .net te reflection sayesinde kutuphanelerin private, internal vb uyelerine de uygulayabileceginiz, bir yazilim test metodu.
  functional testing ile mumkunse birlikte kullanilmasi daha iyi code coverage saglar.
• dot net icin (bkz: nunit)
• (bkz: phpunit)
  (bkz: pyunit)
  (bkz: perlunit)
• syntax hatalarini kismet bulsa/test etse de performans testini kapsamaz. performans testlerini kapsamamasinin sebebi ise test suresinin uzamamasi icindir. birim testleri standart build surecinde calisacagi icin mumkun oldugunca kisa surede bitmelidir. genelde performans testleri icin ayri bir build surecinde/profilinde calistirilarak test edilir. hatta testlerin kisa surmesi icin mumkun oldugunca mock objeler kullanilmali, stub obje yaratmak, reflection kullanarak katakullilere girmekten kacinilamalidir. mumkun oldugunca mock objelerinin kullanilabilecegi disiplin kodun daha yalin yazilabilmesi icin etkilidir de.
  bir baska hususta domain/bussiness kodunun bir developer, testlerin ise baska bir developer tarafindan yazilmasidir. tdd disiplini uygulaniyorsa eger bu kafadan hatali bir yaklasimdir. tdd de kilit noktalardan birisi once test kodu sonra domain kodu oldugu ve kodun bu sekilde gelismesi/olgunlasmasi ongoruldugunden ikisinin de ayni code tarafindan ilk asamada yapilmasi daha makbuldur, test konusunda uzmanlasmis bir pair ile yapilabilir^* fakat surekliligi domain code yazan developeri temebellige alistiracagindan tercih edilmez pek. daha sonraki asamalarda code review surecinde baska developer, test engineerlar tarafindan testler genisletilebilir. yine integration test asamasinda testlerin genisletilmesi de sik rastlanilan bir sonuctur.
  
  efendim, bunca cok bilmislikten sonra isin ozune donersek eger test edilen birimin mumkun oldugunca kendi icerisindeki fonksiyonalitesinin test edilmesine dayanir. bu yaklasim ayni zamanda yazilim tasarimina loosely coupled - high cohesion yaklasimini da getirir bir yandan. birimlerin^* sadece tek bir ise odaklanmasina tesvik eder. ornegin basit bir xml unmarshaller test edecegimizi varsayarsak yazacagimiz test mumkun oldugunca amaca yonelik olmalidir. unmarshall edilecek dosya sistemden okunmaz, fonksiyona dosya mock objesi parametre olarak gecilmeli ya da constructorda verilmelidir, baska bir yaklasimda use dosyayi okuyan birim mocklanmali ve bu mocklanmis birimin dosya okuma fonksiyonu taklit edilmeli, ardindan taklit edilen fonksiyonlarin dogru sekilde calistigi onaylanmali^* en son olarak da elde edilen cikti ve beklenen cikti karsilastirmalidir. bu sayede birimin asil islemi diger birimlerin islemlerinden bagimsiz halde test edilebilir. butun bu mocklama vs. gibi islemler icin javada easymock, mockito gibi kutuphaneler mevcuttur. bu kutuphanelerin fonksiyonlarinin zenginlestirilmesi icin de powermock gibi sahane bir baska kutuphane de vardir ki cana can katar.
  
  birimler kendi iclerinde test edildikten sonra "aga bunlar kendi kendilerine calisiyorlar iyi guzel de hep beraber durum nasil acaba" diye merak eder dogal olarak insan oglu. iste bunun icin bir sonraki asamaya gecilebilir, integration test.
  
  ayrica bakmakta fayda vardir, (bkz: continous integration) (bkz: maven) (bkz: bamboo) (bkz: jenkins)
• (bkz: input)
  (bkz: expected)