Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Mock'u Ne Zaman Kullanmamalı: Over-mocking, Kırılgan Testler ve "Sahibi Olmadığını Mock'lama"
Mock yalnız sistem sınırında, dışarıdan gözlenebilen unmanaged bağımlılıklar için kullanılır; domain object'leri ve uygulamanın kendi veritabanı mock'lanmaz. Mock'lanmış bir döviz kuru adapter'ı testleri yeşil tutarken production'da 100 EUR'yu 0 TRY gösterdi; HttpMessageHandler stub'ı hatayı ilk koşuda yakaladı. Output, state ve communication test stilleri ve managed/unmanaged ayrımı.
Mocking Kütüphaneleri Derinlemesine: NSubstitute, Moq ve FakeItEasy
NSubstitute, Moq ve FakeItEasy aynı Castle DynamicProxy motorunu kullanır; bu yüzden yalnız interface ve virtual member'ları taklit edebilir ve aralarındaki fark büyük ölçüde syntax ile hata mesajlarıdır. Aynı ödeme senaryoları üç kütüphaneyle: argument matching ve yakalama, ardışık dönüş, async exception, çağrı sayısı ve sırası, strict mod, NS1000 analyzer uyarısı ve Moq'un 2023 SponsorLink olayı.
Test Double'lar: Dummy, Stub, Spy, Mock ve Fake Arasındaki Fark
Bir test double'ın türünü kütüphanesi değil testteki rolü belirler: dummy yer doldurur, stub veri verir, spy ve mock dışarı giden çağrıyı doğrular, fake çalışan bir kestirmedir. Meszaros taksonomisi, Fowler'ın state ve behavior verification ayrımı, stub'a assert etmenin zararı, kaydı kopyalamayan bir fake'in eksik SaveAsync'i nasıl gizlediği ve FakeTimeProvider ile FakeLogger.
Unit Test'te "Unit" Ne Demek? Classical ve London School, İyi Testin Dört Özelliği
Unit, bir method ya da class değil bir davranıştır; test double'ı yalnız sistem sınırında kullanan classical school, her collaborator'ı mock'layan London school'dan daha refactoring'e dayanıklı testler üretir. Solitary ve sociable test ayrımı, Khorikov'un iyi testin dört özelliği ve davranışı aynı bırakan bir değişikliğin mock'lu testi nasıl kırdığı gerçek çıktıyla.
Neyi Hangi Seviyede Test Etmeli? Davranış, Sınırlar ve Mock'lanacak Bağımlılıklar
Domain mantığı yoğun unit test, orchestration kodu az sayıda integration test alır; trivial kod test edilmez, aşırı karmaşık kod önce refactor edilir. Testte kendi veritabanın (managed) gerçek, ödeme ve e-posta gibi unmanaged bağımlılıklar mock olur. Davranışı değişmeyen bir refactoring'de kırılan mock'lu testin gerçek çıktısı, risk tabanlı önceliklendirme ve tek sayfalık test stratejisi dokümanı.