Tekrar hoş geldiniz.
Daha önce yazdığımız bir kod parçasını tekrar gözden geçirerek eğlenceli bir alıştırma yapalım.
Bir ile on arasında bir sayı tahmin etmemiz gereken rastgele sayı tahmin oyununu hatırlıyor musunuz?
Bu dosyayı çalıştırırsam, bunu görüyor musun?
Benden tahmin etmemi istedi.
Yani bir, iki, üç, dört, beş, altı, yedi, sekiz, dokuz diyelim.
Ve sonunda numarayı aldım.
Sen bir dahisin.
Sayı dokuzdu.
Peki bu kodu nasıl test edebiliriz?
Şimdi, burada fark edeceğiniz bir şey, gerçekten bir fonksiyonumuz olmadığıdır.
Size fonksiyonel programlamadan ve kodumuzu tek bir şeyi, özellikle de saf fonksiyonları
çok iyi yapan küçük fonksiyon parçalarına ayırmanın ne kadar iyi olduğundan bahsettiğimi hatırlayın.
Bu zihniyetin en büyük faydalarından biri, test edilmesi gerçekten çok kolay kodlar oluşturmanızdır.
Testlerimizde gerçekten karmaşık bir mantığa sahip olmak yerine, fonksiyonlarımıza basitçe bir girdi verebilir
ve bir çıktı bekleyebiliriz.
İşte bu yüzden birim testlerimiz var.
Birim testinin ana fikri, her bir birim parçasını test ediyor olmamızdır.
Bu birim testleri, bu basit işlevleri test eden küçük küçük parçalardır.
Bu yüzden size meydan okumam, bu kodu kullanmanız ve bunu basit işlevlere ayırmaya çalışmanızdır.
Şimdi.
Bizim durumumuzda, kodun sadece tahmin kısmı olan ve bir girdi aldığımız bu kısmını test etmemizi istiyorum.
Bu tahmin olacak ve daha sonra elimizdeki rastgele bir cevaba karşı test edeceğiz ve bir tür çıktı beklemeliyiz.
Yani ya bir sayı gireceğiz.
1'den 10'a kadar olmalı.
Ve eğer doğru yaparsak, ipi almak zorundayız.
Ancak buradaki kilit nokta, muhtemelen bunu test edebileceğimiz bir fonksiyona taşımak istememizdir.
Dış dünyayı görmezden gelebiliriz.
Ve bunu kendi küçük işlevine ayırın.
Bu yüzden videoyu burada durdurun ve bir deneyin.
Bazı engelleri aşmanız gerekecek, ancak test anlayışınızı gerçekten test
edecek.
Ha ha.
Komik.
Bu bir kelime oyunuydu.
O yüzden videoyu durdurun ve bir deneyin.
Aksi takdirde, cevapla devam edeceğim.
Yapmak istediğim ilk şey testimi yeniden kurmak.
Birim testini içe aktaracağım ve main test sınıfını oluşturacağım.
Ya da bu sefer test senaryosu veya test oyunu diyelim.
Birim testi diyeceğim.
Test durumu.
Bu bizim test vakamız olacak.
Ve sonra burada diyelim ki basit bir test oluşturacağım.
Oyun veya test girişi.
Kendini kabul et.
Ve şimdilik bunu geçiyorum çünkü gerçekten bir şey yapmıyoruz.
Son olarak, eğer diyeceğim.
Adlandırın çünkü iki ana sonra birim testini çalıştırın.
Ana nokta.
Yani bu sadece bizim basit kurulumumuz.
Şimdi bunu çalıştırırsak, diyelim ki Python üç.
Test pi.
Bir test yaptığımızı görüyoruz.
Tamam.
Bu bizim düzenimiz.
Daha sonra, yapmak istediğim şey aslında bunu bir fonksiyona çıkararak test dosyamda kullanabilmek.
Bu yüzden burada en üstte söyleyeceğim.
Tahminimizi tanımlayacağım.
Oyun ya da koşu diyelim.
Tahmin et.
Bu bir girdi alacak.
Ya da bir tahmin diyelim ve sonra bu kodu çalıştıracak.
Hadi yapalım şunu.
Ben alacağım.
Bu kod parçası.
Bunun gibi.
Ve basitçe buraya yapıştırın.
Şimdi yanlış tahmin de cevap değişkenine ihtiyaç duyacaktır.
Bu yüzden ikinci bir parametre cevabı vereceğim.
Bunun gibi.
Böylece artık sadece buranın içine girebiliyorum.
Bu fonksiyonu tahmin ve cevap ile çalıştırın.
Aynen böyle.
Şimdi buraya kaydedelim ve bu testi çalıştıralım ya da hala çalıştığından emin olmak için asıl dosyayı çalıştıralım.
Oh, ve orada biraz girinti var.
Bu yüzden girintimizin doğru olduğundan emin olmalıyız.
Çünkü Python'da bunun bir anlamı olduğunu unutmayın.
Tamam.
Şimdi bir sorunumuz var.
Döngünün dışında bir kırılmamız var çünkü kırılma anahtar kelimesini kullanırken şu anda bir döngünün
dışındayız.
Yani yapabileceğimiz tek şey buraya geri dönmek.
O zaman tekrar çalıştıralım.
Ve bir isim tahmin etmeye devam et.
Ya da bir sayı.
Ve işte oldu.
Bu hala çalışıyor.
Burada geri dönüşü kullanabiliyorum çünkü bu kuyu çalışacak ve geri dönecek.
Ama şimdi hâlâ oyunun içindeyiz.
Belki de geri dönebiliriz.
Doğru.
Ve eğer de.
Tahmin et.
Bu doğru.
Bundan kurtulacağız.
Tekrar.
Oyunumuza başlayalım.
Bunu temizleyeceğim ve oyunu tekrar çalıştıracağım.
Bir, iki, üç, dört.
Ve işte oldu.
Bir numara girdim.
Ben bir dahiyim.
Oyunu yeni bitirdik.
Görebilmeniz için bunu biraz daha küçültelim.
Yani kaçışımız var.
Sanırım kodu biraz değiştirdim.
Ancak önemli olan, Run gibi bir şeyi test edebilmem için bir işlevsellik birimi çıkarmış olmam.
Tahmin et.
Yani kodumuzu değiştirmişim gibi görünüyor, ancak kod hala çalışıyor.
Şimdi run guess fonksiyonumuzu test etmeye başlayalım.
Şuraya gidelim.
Ve senaryomuzu içe aktarmaya başlayın.
Ve burada birkaç şey yap.
İlk olarak, cevabın diyelim ki beşe eşit olmasını istiyorum.
Ve tahmin 5'e eşit olacak.
Bu nedenle, tahmin ve cevap eşleşirse, yanlış misafirin if ifadesinden geçtiğinden ve bir dahi
olduğunuzu yazdırdığından veya bir non case'in true döndürdüğünden emin olmak istiyoruz.
Yani self dot assert diyelim.
Eşit.
Bu betiği ya da aslında ilk seferinde gerçekten çalıştıralım.
Sonuç, kod noktasına eşit olsun.
Neydi o?
Koş, tahmin et.
Koş.
Tahmin et.
Ve ona cevabı ver.
Ve tahmin et.
Ve sonucun da böyle olmasını bekliyoruz.
Geri dön.
Doğru.
Bu yüzden doğru olduğunu iddia edebiliriz.
Sonuç doğru.
Eğer şimdi bunu çalıştırırsam.
Oh, aslında oyuna başlıyoruz.
Peki bunu nasıl düzeltebiliriz?
Pekala, bunu kapatabilir ve if adını Main olarak ekleyebiliriz.
Burada.
Yani burada.
Diyeceğiz ki, hey, bunu yalnızca ana dosya bu şekilde çalıştırılıyorsa çalıştırın.
Buradaki teste geri dönüp bunu tekrar çalıştırırsam.
Tamam.
Şimdi çalışıyor ama bir assertion hatası alıyorum test game object has no attribute assert true because.
Şey, ben.
Yanlış yazdın.
Tekrar deneyelim.
Tamam.
Görünüşe göre bir test yapılmış ve her şey yolunda.
Ayrıca çıktı alındığını da görüyoruz.
Sen bir dahisin.
Çok, çok güzel.
Bu arada, size bu test yöntemini gösteriyorum çünkü gerçek hayattaki bir senaryo böyle görünüyor.
Bir şeyleri bozmaya, hatalar yapmaya devam edersiniz ve sonra bunları düzeltmeye ve kodunuzu düzeltmeye çalışırsınız.
Ve sadece bu testleri çalıştırarak kodumuzun şimdiden daha iyi göründüğünü görebilirsiniz.
Tamam.
Başka ne yapabiliriz?
Şöyle diyelim.
Bunu kopyalayacağımızı.
Ve her şeyin daha kısa olması için, parametreleri doğrudan buraya gireceğim.
Aynen böyle.
Diyelim ki girdi, diyelim ki yanlış.
Ya da.
Yanlış tahmin.
Diyelim ki cevap beş ve sanırım sıfır.
Bu yüzden bunun yanlışa eşit olacağını iddia etmek istiyoruz.
Yani bunu çalıştırırsam.
Geçişlerini test etmek için.
Bu harika.
Burada başka neyi test edebiliriz?
Tamam.
Tahminin sıfır ile on arasında ya da bir ile on arasında olup olmadığını test etmek istiyoruz.
Bu durumda, bir baskı almak istiyoruz.
Hey, Bozo.
1'den 10'a kadar dedim.
Yani bir kez daha test edebilirim.
Eğer tahminim yanlışsa.
Numara.
Diyelim ki cevap 5, ama ben 11 veriyorum.
İddia etmek istiyoruz.
Şu anda baskı yapıyoruz ve hiçbir şey yapmıyoruz.
Belki de burada biraz tutarlılık olması için false değerini döndürmeliyiz.
Yine bunu yaparsam ve kaçarsam.
Al bakalım.
Üç test geçiyor.
Bu harika.
Ve yazabileceğimiz daha pek çok test var.
Belki bir test daha yapalım, yani test edelim.
Girdi bir dize ise ne olur?
Eğer bunu çalıştırırsam.
Oh.
Ve bunun yanlış olduğundan emin olun.
Buraya yazın.
İsimlerin farklı olduğundan emin olun.
Ve çalışan dört testim var.
Çünkü bu geçmeyecek ve yanlış dönecektir.
Şimdi burada yapabileceğimiz daha pek çok şey var.
Ama testin gücünü şu anda görebilirsiniz.
Benden farklı testleriniz varsa, sorun değil, millet.
Test senaryoları farklıdır.
Test etmenin tüm amacı sadece basitçe.
Kodumuza bakın ve onu nasıl geliştirebileceğimizi, kodumuzu nasıl kırabileceğimizi, kodumuzu daha küçük birimlere,
test edilebilecek daha küçük birimlere ayırarak nasıl basitleştirebileceğimizi ve belki de düşünmek istediğimiz bazı hataları nasıl
düzeltebileceğimizi görün.
Şimdi yapabileceğimiz daha pek çok şey var, ancak burada fikrin her seferinde küçük bir parça üzerinde çalışmak olduğunu
fark edeceksiniz.
Bunu test edin ve belki daha sonra kodun bu kısmına ya da kodun deneme ve kabul kısmına bakabiliriz.
Ve olay şu.
Bir şirket için çalışıyorsanız, yapabileceğiniz sonsuz sayıda test olduğunu iddia ediyorum.
Kodunuzu test etmek için burada yüzlerce satıra sahip olabilirsiniz.
Ancak mümkün olduğunca çok sayıda test yapıyor olmanız testlerinizi gerçekten iyi yapmaz.
Dediğim gibi, yazabileceğiniz sonsuz sayıda test var.
Buradaki fikir, vakalarınızın çoğunu kapsayan iyi kalitede testler yazmaktır.
Ancak eninde sonunda, kod yazmak ile test yazmak arasında bir denge kurmanız gereken azalan getirilere
sahip olacaksınız.
Ve bazen, işin gerektirdiklerine bağlı olarak, testlere daha fazla odaklanmanız ve koda daha az odaklanmanız
gerekebilir.
Ya da bazen hızlı hareket etmeniz gerekir ve test yazmak için zamanınız olmayabilir.
Ve yine, iş ihtiyaçlarına bağlı olarak, bu da söz konusu olabilir.
Ancak bu bölümle birlikte, yazılım geliştirmede testin ardından gelen bazı ilkeleri anladığınızı umuyorum.
Yani, kodumuzda her zaman hatalar ortaya çıkacaktır.
Ve bu konuda bize yardımcı olması için aydınlatmayı kullanabiliriz.
Ancak kodumuzun düzgün çalıştığından emin olmanın en iyi yollarından biri test etmektir.
Ve ne kadar çok test yaparsak kodumuz o kadar istikrarlı olur.
Bir sonrakinde görüşürüz.
Güle güle.