Çözüldü Unit testin önemi nedir?
- Konuyu başlatan 706111
- Başlangıç Tarihi
- Mesaj 5
- Görüntüleme 392
Bu konu çözüldü olarak işaretlenmiştir. Çözülmediğini düşünüyorsanız konuyu rapor edebilirsiniz.
Çözüm
Bazi fonksiyonlarin baska fonksiyonlara bagimli olmasi onlari teste sokmak icin bir engel degil yada sureci karisiklastiracak bir sey degil. En kucuk fonksiyonlarindan basla unit testlerini yazmaya. Tek bir isi yapan fonksiyonlardan bahsediyorum. Oraya gelecek datayi da test case olarak koy.
Unit testleri ve programin kodlari bir birlerinden bagimsiz, nasil kafa karisikligina yol acsin? Baska bir kavramla karistiriyorsun sanirim.
Fonksiyonlari, yapilari vs test fonksiyonuna veriyorsun, test case ve beklenen sonuclari hazirliyorsun, sonra test ettiriyorsun. Eger calisma sirasinda herhangi bir exception, crush veya undefined behaviour yasanirsa, yada test sonuclari tutarsizsa ve beklenen yanitlari, yada beklenen calisma suresini saglamiyorsa biliyorsun ki kodunda bug var ve duzeltmen gerek.
Mesela C++'ta gtest ile;
Farkli bir dosyadayiz, yazdigimiz kodu buraya include ettik ve test ettik. Mantigi bu. O yuzden kafa karistiracak bir sey yok. Eger Add fonksiyonu dogru cikti vermezse hata verecek. Tabii ki tum testler sadece dogru sonuc vermeye yonelik degil. Random crush testleri, time limited testler gibi bir kac test cesidi de var. Ama basit bir ornek.
Testler kodun kendisinden farkli bir yerde durur yada cesitli makrolar vardir bir fonksiyonu test icin isaretleyen vs vs. Ama kodla beraber karisik bir bicimde yer almaz. Dedigim gibi, muhtemelen baska bir kavramla karistiriyorsun.
Basliga gelecek olursam, fazlasiyla onemli.
Fonksiyonlari, yapilari vs test fonksiyonuna veriyorsun, test case ve beklenen sonuclari hazirliyorsun, sonra test ettiriyorsun. Eger calisma sirasinda herhangi bir exception, crush veya undefined behaviour yasanirsa, yada test sonuclari tutarsizsa ve beklenen yanitlari, yada beklenen calisma suresini saglamiyorsa biliyorsun ki kodunda bug var ve duzeltmen gerek.
Mesela C++'ta gtest ile;
C++:
#include <gtest/gtest.h>
#include "Calculate.hpp"
/* Mesela bu Calculate.hpp'de yer alan Add diye bir fonksiyonumuz var.
MathTest dedigimiz kisim, Test icin bir nevi namespace, ana grup
Addition dedigimiz kisim, alt grup ve testin kendisi. Testleri
calistirdigimizda asagi yukari soyle bir cikti veriyor;
[==========] Running 1 tests from 1 test case.
[‑‑‑‑‑‑‑‑‑‑] Global test environment set‑up.
[‑‑‑‑‑‑‑‑‑‑] 1 tests from MathTest
[ RUN ] MathTest.Addition
*/
TEST(MathTest, Addition) {
EXPECT_EQ(Add(2, 3), 5); // Beklenen: 5
EXPECT_EQ(Add(-1, 1), 0); // Beklenen: 0
EXPECT_EQ(Add(0, 0), 0); // Beklenen: 0
}Farkli bir dosyadayiz, yazdigimiz kodu buraya include ettik ve test ettik. Mantigi bu. O yuzden kafa karistiracak bir sey yok. Eger Add fonksiyonu dogru cikti vermezse hata verecek. Tabii ki tum testler sadece dogru sonuc vermeye yonelik degil. Random crush testleri, time limited testler gibi bir kac test cesidi de var. Ama basit bir ornek.
Testler kodun kendisinden farkli bir yerde durur yada cesitli makrolar vardir bir fonksiyonu test icin isaretleyen vs vs. Ama kodla beraber karisik bir bicimde yer almaz. Dedigim gibi, muhtemelen baska bir kavramla karistiriyorsun.
Basliga gelecek olursam, fazlasiyla onemli.
Ya şimdi birim test olayını çok irdelemeden dünya kadar kod yazdım. Hepsini o an için doğru çalışması adına çok test ettim ama birim test gibi parçalara ayırıp değil de acaba yanlış nerede şeklinde hiç fonskiyonların bağımlılıklarını birbirinden ayırmadan yaptım.
Böyle bir projeye şimdi tek tek birim test uygulamak, işleri de daha da zorlaştırır yani. Ben de öğreniyorum yeni yeni birim test kavramını, çok önemliymiş hakkatten. En başta yapmam gerekirmiş yani.
Hani karmaşık bir koda benim dediğim şekilde test uygulamak başka bir yöntemse onu bilmiyorum.
Bazi fonksiyonlarin baska fonksiyonlara bagimli olmasi onlari teste sokmak icin bir engel degil yada sureci karisiklastiracak bir sey degil. En kucuk fonksiyonlarindan basla unit testlerini yazmaya. Tek bir isi yapan fonksiyonlardan bahsediyorum. Oraya gelecek datayi da test case olarak koy.
- Katılım
- 22 Mart 2018
- Mesajlar
- 9.604
- Makaleler
- 1
- Çözümler
- 81
Kod kalitesini belirleyen unsurlarda cok ust siralardadir. Kodun karisik olmasi bunu yazmana engel degil ancak testable kod yazabilmek de onemli. Hiyerarsinin icinden gecen side effect dolu bir fonksiyonu test etmek de yurek burkan bir deneyim.
Yeterince buyuk bir projede calistiginda kodu test etmek icin projeyi calistirmak, saga sola log atmak ya da gerekli zibilyon tane seyi yapmak zorunda kaliyorsan unit-test olmamasinin eksikligini goruyorsun demektir. Ayrica zaten proje buyudukce test amacli calistirmak zorlasir, bazi projelerde zaten compile etmek 45 dk suruyor, sadece ilgili componenti compile edip test edebilirsin.
Unit test elbette tek basina yeterli degil ama saglikli bir projede bagimsiz kullanilabilecek ufak fonksiyonlarin dogru calistigini gostermenin ve dogru calismaya devam ettiginin en kolay yolu. 2 satir kodu yanlis sekilde degistirdiginizde 800 tane test hata aliyorsa guzel bir projede calisiyorsunuz demektir.
Yeterince buyuk bir projede calistiginda kodu test etmek icin projeyi calistirmak, saga sola log atmak ya da gerekli zibilyon tane seyi yapmak zorunda kaliyorsan unit-test olmamasinin eksikligini goruyorsun demektir. Ayrica zaten proje buyudukce test amacli calistirmak zorlasir, bazi projelerde zaten compile etmek 45 dk suruyor, sadece ilgili componenti compile edip test edebilirsin.
Unit test elbette tek basina yeterli degil ama saglikli bir projede bagimsiz kullanilabilecek ufak fonksiyonlarin dogru calistigini gostermenin ve dogru calismaya devam ettiginin en kolay yolu. 2 satir kodu yanlis sekilde degistirdiginizde 800 tane test hata aliyorsa guzel bir projede calisiyorsunuz demektir.
