Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
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.
xUnit v3 ile Test Projesi: Microsoft Testing Platform, dotnet test ve İlk Testler
xUnit.net v3 test projesi bir executable'dır ve 4.0 ile varsayılan olarak Microsoft Testing Platform v2 üzerinde çalışır; .NET 10 SDK'da global.json'a test runner ayarı eklenince dotnet test VSTest projelerini reddeder. xunit3 template'i, paket zinciri, dotnet test ve dotnet run, Assert.Throws/ThrowsAsync, TestContext.Current.CancellationToken ile xUnit1051, filtreler, TRX raporu ve exit code 8.
İyi Bir Unit Test'in Anatomisi: AAA, İsimlendirme, Tek Davranış ve Okunabilir Assertion'lar
İyi bir unit test tek bir davranışı tek bir Act ile çalıştırır, dallanma içermez ve kırmızıya döndüğünde adı ve hata mesajıyla sorunu kodu açmadan anlatır. AAA'nın sınırları, Method_Scenario_Expected ile düz cümle isimlendirme, Assert.Multiple, Shouldly, AwesomeAssertions ve FluentAssertions 8'in Xceed lisansı gerçek hata mesajlarıyla.
xUnit v3'te Veri Odaklı Testler: Theory, MemberData, TheoryData, TheoryDataRow ve MatrixTheoryData
Veri odaklı testte satır sayısından çok satır seçimi önemlidir: sınır değerleri ve equivalence partitioning, Math.Round'un banker's rounding hatasını iki satırla yakaladı. xUnit v3'te InlineData, MemberData ve tip güvenli TheoryData, satır bazında display name, label, trait ve skip taşıyan TheoryDataRow, MatrixTheoryData, dinamik skip, Explicit testler ve serileştirilemeyen verinin Test Explorer'a etkisi.
xUnit Test Yaşam Döngüsü: Constructor, IAsyncLifetime, Fixture'lar ve 4.0'da Tam Paralellik
xUnit her test için test class'ının yeni bir instance'ını oluşturur; pahalı ve salt okunur hazırlık class, collection ya da assembly fixture'ında bir kez yapılır. 4.0'ın ParallelMode.All'u 8 testlik örnekte süreyi 1,06 saniyeden 0,55'e indirdi, ama static bir fake paylaşan iki test 20 koşunun 16'sında kaldı. IAsyncLifetime, opt-out seviyeleri, ITestOutputHelper ve TestContext ekleri.
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.
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ı.
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ı.
Test Edilebilir Tasarım: Dependency Injection, Seam'ler, Functional Core ve Humble Object
Kodu test edilebilir yapan şey kararları saf bir çekirdeğe çekip zamanı, I/O'yu ve çerçeve kodunu ince bir kabukta bırakmaktır; o zaman kararlar mock'suz test edilir. DateTime.Now kullanan bir indirim testi takvime bağlı kaldı ve İstanbul ile UTC farkını gizledi. Seam türleri, TimeProvider, functional core / imperative shell, Humble Object ile BackgroundService ve legacy kod için characterization test.
Test Kodunu Temiz Tutmak: Test Data Builder, Object Mother, AutoFixture ve Bogus
Test verisinde kural basit: testin dayandığı değer testte açıkça yazılır, gerisi anlamlı varsayılanlara ya da anonim veriye bırakılır. Seed'siz Bogus verisiyle yazılmış bir kargo testi 30 koşunun 6'sında kaldı. Test Data Builder, Object Mother'ın büyüme sorunu, AutoFixture ve AutoData, AutoNSubstitute'un NSubstitute 6 ile NU1608 uyarısı, sabit seed'li Bogus ve test kodunda DRY ile DAMP dengesi.
Unit Test'te Zor Durumlar: Async Kod, Zaman, Exception'lar, Logging ve Background Service'ler
FakeTimeProvider ile test edilen kodda kural şudur: işlemi başlat, saati ilerlet, sonra bekle; önce await edilen retry testi saat hiç ilerlemediği için 2 saniyelik timeout'a takıldı. Backoff'u saf fonksiyon olarak, retry akışını fake saatle, exception'ı tip ve veriyle, critical log'u FakeLogger ile, cancellation'ı ve Channel<T> tüketen BackgroundService'i deterministik testlerle doğrulamak.
Snapshot ve Property-based Testing: Verify ve FsCheck ile Unit Test'in Sınırlarını Genişletmek
Property-based testing her girdi için doğru olan bir kuralı rastgele girdilerle dener, snapshot testing büyük çıktıyı bir bütün olarak onaylar; ikisi de örnek testleri tamamlar. FsCheck, üç örnek testin kaçırdığı negatif toplamı ilk denemede bulup 0 EUR'luk sepet ve 1 EUR'luk kupona küçülttü; Verify bir alan adı değişikliğini sözleşme farkı olarak yakaladı. Shrinking, özel arbitrary, scrubber'lar ve Verify 33'ün bakım ücreti kontrolü.