Test için araç kutusu ve kullanma talimatları
Merhabalar herkese,
Kısa giriş yazımız sonrası test için araç seçimi ve seçilen araçların kullanımı konusundaki tecrübelerimizi sizinle paylaşmak istiyoruz. Test yazıyorum ama hangi araçları veya ürünleri kullanmalıyım, bu araçlar gerçekten ne işime yarar diyenler ve .Net geliştiricisi olanlar bu yazı sizler için.
Serinin diğer yazıları için;
1- Unit test
2- Test için araç kutusu ve kullanım talimatları
3- Test yazarken bilmeniz gerekenler sıralı tam liste (yakında)
4- Unit test türleri nelerdir ve hangileri işinize yarar? (yakında)
5- Moq’nun efektif kullanımı (yakında)
6- Unit test için design pattern’lar (yakında)
7- Testable architecture’a doğru (yakında)
8- Testable architecture (yakında)
9- Temel TDD (yakında)
10- Eski projelerinize yeni bir soluk TDD (yakında)
11- Advanced Unit Testing Teknikleri (yakında)
12- AspNet Core için Unit Testability (yakında)
Test araçları ihtiyaçlarını belirlemek
İlk önce hangi tipte test yazacağınızı belirlemeli ve ona göre toolkit’inizi oluşturmalısınız. Her firmanın kendine özgü bir toolkit’i olacaktır. Bizim hesapkurdu.com dahilinde ana işimiz website ve API geliştirmeleri olduğu için integration test, unit test ve smoke test daha öncelikli bir liste oluşturuyor. Bunları takip eden ihtiyaç listemizde UI test, A/B testing var.
Kullandığımız araçların tam listesi şu şekilde;
1 — xUnit.Net
2 — Moq
3 — FluentAssertions
4 — Microsoft AspNetCore Mvc Testing
5 — AutoFixture
6 — DotCover
7 — Newman
8 — Google A/B testing
9 — Selenium
10 — BrowserStack
Testing Framework — xUnit.Net
Test yazacaksak minimumda bir test framework’üne ihtiyaç var. Biz xUnit.Net’te karar kıldık. Bu framework’ü seçmemizin temel sebebi genişletilebilir olması. “Ne demek bu genişletilebilirlik?” diyorsanız mesela Selenium’la UI testten tutun da data-driven testlere kadar çok fazla alanı test edebilecek bir yapı diyebilirim. xUnit basit bir kullanımla Database’i fixture ile kullanabiliyorsunuz bu sayede kod tekrarını engelleyen güzel temiz yapılar olutşurabiliyorsunuz. xUnit; .Net Core ile tamamen uyumlu! Eğer sizde .Net Core’a geçecekseniz ya da .Net Core kullanıyorsanız xUnit ciddi oranda fayda sağlayacaktır.
Teardown ve setup yapıları diğer framework’lerdeki gibi yok ama bunu zaten bilinen pratikler ile çözebiliyorsunuz. IDisposable kullanarak ve class constructor’larında setup ve teardown adımlarını kurgulayabiliyorsunuz. Yani daha temiz, daha az kod içeren kodlarla daha güzel bir test yapısı sunuyor.
Yukarıdaki kodu dotnet cli ile çalıştırabiliyor ve sonucu alabiliyorsunuz. Ayrıca Visual Studio’nun neredeyse tüm versiyonlarına desteği var ve oradaki Test Explorer ile kullanabiliyorsunuz.
Mock Framework — Moq
Test için Mock olmazsa olmazlardan biri diyebilirim. Bu konuda çok fazla alternatif var ama Moq gayet basit ve anlaşılır bir yapı sunduğu için bunu tercih ettik. Mock kullanmak yerine fake object yaratıp testlere onları inject eden çok fazla developer var. Bu şekilde de geliştirme yapabilirsiniz ama bu gereksiz bir kod kalabalığı yaratıyor. Zaten Mock Framework’leri sayesinde ekstra class vb. oluşturmadan yapabiliyorsunuz. Aşağıdaki örneklerle nedenini daha iyi anlayacaksınız.
Bu kadar basit bir şekilde bir yapıyı mock’layabilirsiniz. Inject edilip çağrılan servisin nasıl isterseniz o şekilde dönüş object’lerini ayarlayabilirsiniz.
Moq’nun güzel bir özelliği olarak istenilen parametreye göre istenilen dönüş verilebiliyor.
Çok sevdiğim özelliklerden biri olarak Moq’da bir method’un en azından bir kere çağrılmış olup olmadığını kontrol edebileceğimiz bir yapı var. Bu sayede foreach veya if gibi koşullu durumlarla geliştirdiğimiz bir method içerisinde çok kez çağrılan bir method kontrolü yapabiliriz ya da yollanan her object için bir method çağrılacaksa listenin count’u ile method çağrısı sayısının eşitliğine bakabiliriz. Bana kalırsa güzel bir yetenek.
Assertion framework — Fluent Assertions
Bunu kullanması son derece opsiyonel bir durum ancak kullanımı daha temiz daha anlaşılır test kodu yazabilmemizi sağlıyor. Amaç zaten temiz kod yazmak olduğu için burada assertion framework’leri ciddi bir şekilde yardımcı oluyor. FluentAssertions dışında çok fazla alternatif var, mesela Shouldly’de iyi bir alternatif ama çok ciddi bir fark olmadığı için bunu kullandık. Genel olarak mantıkları aynı, siz de herhangi birini kullanabilirsiniz.
FluentAssertions; temelde testlerimizde Assert basamağında yaptığımız işi daha basitleştirerek yapan bir library. Bir object veya value’nun eşitliği ya da count’ını kontrol etmek için bir statement yazana kadar bunu built-in method’lar ile yapabiliyoruz ve fail sebebini yazabiliyoruz. Bu da unit test raporu alıp kontrol ettiğimizde hatanın temel sebebi konusunda ciddi bir yardım oluyor. Yani test fail etti ama neden etti, developerlar bu açıklamaları da yazarsa çok güzel bir testing yapısına kavuşuyoruz.
Microsoft AspNet Core Mvc Testing
Bu sadece AspNet Core’a özel yapı. Bize mevcut API’yi ayağa kaldırıp Unit test yapabilmemizi sağlıyor. Bu şekilde mevcut API’lerimize Http Request atabiliyoruz. Attığımız requestlerden beklenen cevabı assert ederek güçlü bir API kurgusu yapabiliyoruz. Sadece istenen paremetrelere göre yanıt verip vermediğini olası farklı bir durum oluşmadığını teyit için çok güzel bir yapı. Sadece API’nin testini yazıp arkadaki servis ve DAL katmanlarını kolay bir şekilde refactor etmemize olanak sağlıyor. Bunu yaparken her zaman API’nin istenilen cevabı üretebildiğinden emin olabiliyoruz. En büyük artısı developer’ın bilgisayarında normal bir Unit test yapar gibi çalıştırması yeterli oluyor.
Arrange Library — Autofixture
Testlerde her aşama için bir araç olduğu gibi arrange aşaması için de var. Arrange aşamasında bir servis için parametre ayarlarken Autofixture bunu otomatik olarak yapabiliyor. Bize sadece testin kurgusunu yapmak kalıyor. Kompleks bir object’inizi olduğu durumda 20 property’i tek tek set etmenize gerek kalmıyor. Ayrıca özel bir property’i set edip diğerlerini sen türet de diyebiliyoruz. Extendable yapısı sayesinde email generator, phone number generator gibi yapılar kurup, adında phone, email vb. geçen property’leri bizim yazdığımız generator ile üretebiliyoruz. Bu da ciddi bir avantaj sağlıyor. Bu yapıyı ve üstte bahsettiğim yapıları kullanarak son derece temiz bir yapı elde edebilirsiniz.
Bu library’i tercih etmemizin sebeplerinden biri Moq ve xUnit ile tam uyumlu çalışıyor.
Code Coverage — DotCover
DotCover bir unit test coverage aracı. Unit testlerin kodun ne kadarını cover ettiğimizi gösteriyor. Bunu seçmemizin temel sebebi development ortamlarında VS’lere entegre bir şekilde Resharper kullanmamız. Resharper içerisinde built-in olarak geliyor. Gayet başarılı bir ürün. Hem test session yönetimi hemde live unit testing ile uyumlu çalışarak anlık coverage göstermesi çok başarılı. Dev ortamlarında coverage’a bu şekilde baktığımız için CI’da da unit test raporları dotCover’dan almak daha doğru olacağını düşündük. Bu sayede CI’ımız her çalışmasında bir rapor üreterek coverage’ımızı kontrol altında tutmamızı sağlıyor. Bir avantaj olarak da dotCover’ı başka bir sunucuya kurup remote olarak çalışmasını sağlayabiliyorsunuz bu da dev ortamları ve devops ortamları için bize CPU kazancı olarak geri dönüyor. dotCover’ın diğer bir yeteneği de istediğimiz kod bloklarını ve dosyalarını coverage dışında bırakabiliyoruz, bunlar için Attribute’lar ya da notasyon kullanabiliyoruz. Bu sayede de integration reference.cs’lerini almayarak daha doğru bir sonuç elde etmemizi sağlıyor.
API Testing — Newman
Newman hepimizin bildiği postman’in cli versiyonu. Postman’de oluşturduğunuz run script’lerini newman direk çalıştırabiliyor. Biz Newman’ı smoke test için kullanıyoruz. Tüm websitesini gezeriyor ve 200 cevabını bekliyor. Bu sayede major bir problem olmadığını teyit ediyoruz. Bunu VS’deki Test explorer’dan çalıştıramıyoruz ama mevcut projenizdeki build klasörüne scripti ekleyip cake build ile bir task yazabilir ve oradan çalışmasını sağlayabilirsiniz. CI’da da herhangi bir cli çağrısı yapmanız yeterli oluyor.
Google A/B testing
Bu araç google scripti ile çalışıyor ve ücretsiz. Bizim gibi public bir websiteniz varsa bunu entegre edip denemelere başlayabilirsiniz. Sayfa içi yerleşimi ya da renkleri değiştirerek yeni çıkartmayı düşündüğünüz ürünleri test edebilir bunların nasıl perform edeceğine bakabilirsiniz. Tamamen Google’un size sunduğu ekrandan yönetilebilen bir araç. Kullanımı google’dan daha iyi anlatamam heralde aşağıdaki linkten ürün kullanımı sayfasına girip bakabilirsiniz.
https://support.google.com/optimize/answer/6211930
UI test — Selenium
Selenium bir çok kişinin tercihi olan bir UI test aracı. Web browser automation aracı diye geçiyor. Selenium’u Unit testlerinize bağlayıp butonlara click’lemesi ve beklenen bir yanıt için Assert işlemi yapıp kullanabiliyorsunuz. Login başarılı, başvuru başarılı ya da teklif alıyor gibi kontrolleri otomatize edip ciddi bir manual test yükünden kurtarıyor. UI testi olduğu için doğal olarak çok geniş bir kapsamı kontrol edebiliyorsunuz. Aynı anda bir çok servis yanıtını kontrol etmiş oluyorsunuz. CI üzerinden çalıştırmak için biraz ekstra iş gerekiyor bir Selenium cluster’ına ihtiyacınız olabiliyor. Dezavantaj olarak şöyle bir durum var. Bir başvuru yaptınız ve database kaydı attı ve bunu kontrol etmek istiyorsunuz. Bu sadece click yapan bir yapı olduğu için doğrudan bağlı kayıtları kontrol edemiyorsunuz ama bunu url’e ya da cookie’ye bir şekilde bir identifier basıp Database’i kontrol eden bir yapı kurgulayabilirsiniz. Bir çok firma bu şekilde işlem yaparak kayıtların hala doğru geldiğini test ediyor. Oracle geçen sene yayınladığı bir blogda kendi UI’larını bu şekilde test edip data integrity sağladığını anlatmıştı.
Bu testlerin çalışması inanılmaz zaman alıyor ve developer makinasında çalıştırmak developer’a ciddi zaman kaybı yaratıyor, çünkü Selenium çalıştığı zaman browser popup ediyor orada işlem yapıyor ve bir süre geliştirmeniz duruyor. Bunu CI’da yapmak en doğru çözüm olacaktır. Bu sayede raporlar otomatik olarak developer’a gelecek ve bir hata varsa daha PR(pull request) atmadan farkına varacaktır.
Cross Browser Check — BrowserStack
BrowserStack tüm browser’ları ve çoğu cihazı web üzerinden kullanıp browser özelinde bir hata var mı kontrol etmenizi sağlayan bir araç. Belirtmem gerek ki bu ürün paralı bir ürün ve bu listedeki tek paralı ürün ama parasını sonuna kadar hakediyor. Bu aracı manual testçilerle bile yapıp ciddi bir kazanım elde edebilirsiniz. Bu sayede Safari,Chrome,IE gibi çok kullanılan browser’lara destek verdiğinizden emin olabilirsiniz.
Bu ürün sayesinde biz bir Popup hatasını belirli bir versiyon Safari’de yaşandığını yakalayıp fixlemiştik. En çok para kazandığımız akışlardan biriydi ve ciddi bir şekilde hayatımızı kurtardı.
Mevcut Selenium testlerinizi buraya yönlendirebilir ve tüm browser’larda aynı testi yapmasını isteyebilirsiniz. Bu sayede tüm browser’larda yazdığınız UI testleri çalışır ve gönlünüz ekstradan rahat edebilir. Sonuçta sırf CI’da safari testi yapıcam diye IMac almanız biraz ilginç olurdu.
Size bu yazımızda kullandığımız araçları çeşitli örnekler sunarak anlattım. Test işlerine girerken siz de toolkit’inizi hazırlayın ve geç kalmadan testlerinizi yazın!
Saygılarımla.