Code Coverage

Bu yazımızda .Net Core tarafında geliştireceğimiz kod parçaları için Code Coverage değerlerine nasıl bakabileceğimizi inceleme çalışıyoruz. Bunu yaparken Coverlet kütüphanesi ve SonarQube'ün docker üzerinde çalıştıracağımız versiyonundan yararlanıyoruz. Sonarscanner aracını da işin içerisine katarak test değerlerini SonarQube'e göndermeyi deniyoruz. [Daha fazla]

Teknik Borçları(Technical Debt) Azaltmak

Teknik borçlar pek çoğumuzun bilmeden de olsa gelecek programcılara bıraktığı sorunlar. Bu sorunlar sebebiyle zamanla kalitesi bozulan ürünler ortaya çıkıyor. Teknik borçların temizlenmesi mi, müşterinin yeni isteklerinin karşılanması mı derken ürün üzerinde çalışan programcıları eskitmeye devam edebiliyor. Sonunda legacy olarak tanımlanan, kimsenin ellemek istemediği ama yaşamını devam ettirmek zorunda olan devasa projeler oluşuyor. Bunun önüne geçmek sanıldığı kadar zor değil aslında. En başından test odaklı yaklaşımlarla ilerlemek sadece bir başlangıç. [Daha fazla]

Dependency Injection'ın TDD'deki Yeri

Test odaklı yazılım geliştirirken özellikle entegrasyon testlerinde(Integration Tests) yaşadığımız önemli sorunlardan birisi de test edilen nesnelerin diğer nesnelerle olan bağımlılıklarıdır. Söz gelimi test edilmek istenen birimin bağımlılıkları arasında servis çağrıları, veritabanı operasyonları veya uzak sunucu dosya hareketleri gibi işlemler söz konusuysa otomatik olarak çalıştırılan birim testlerinin CI sürecini sekteye uğratmaması için bir şeyler yapılması gerekebilir. Biliyorum çok karışık bir paragraf ile işe başladım. O yüzden problemi ortaya koymak adına aşağıdaki kod parçalarını göz önüne alalım. [Daha fazla]

Visual Studio Code İçinde Unit Test Yazmak

Bu yazımızda Visual Studio Code içerisinde Unit Test barındıran bir çözümün nasıl geliştirilebileceğini inceliyoruz. İdeal klasör yapısını oluşturuyor, MSTest çatısını kullanarak çok basit bir test vakasını işletmeye çalışıyoruz. Amaçlarımızdan birisi de Visual Studio Code arabirimi dışına çıkmadan proje iskeletini oluşturmak ve testleri kurgulayarak deneyimlemek. [Daha fazla]

Simple Stack ile Bir Başka TDD Pratiği

Code Kata pratiklerine ara vermeden devam etmekte yarar var. Bu videomuzda da Test Driven Development odaklı bir pratiği icra etmeye çalışıyoruz. Çok basit ve ilkel bir Stack sınıfını yazmaya çalışacağız. Bildiğiniz üzere Stack veri yapısı Last In First Out(LIFO) ilkesine göre çalışan bir nesne modeli. Bu code kata senaryomuz için dört farklı test senaryomuz olacak. Stack'e son giren nesnenin çekilmesi, Stack'e birden fazla nesnenin atılıp eklenme sıralarına göre çekilmeleri, boş bir stack oluşturulması halinde null döndürülmesi ve sonr olarak null bir öğenin Stack'e eklenememesi. Bu kez dinlendirici Study Soundtrack listesi eşliğinde ilerliyoruz. [Daha fazla]

FizzBuzz ile Basit Bir TDD Pratiği

DevOps felsefesinin içerdiği önemli pratiklerden birisi de test süreçleridir ve bu noktada TDD(Test Driven Development) büyük önem taşımaktadır. TDD, temel olarak Unit Tests, Integration Tests, User Acceptance Tests gibi pratikleri içerir ve en azından bunların DevOps süreçlerine dahil edilmesi beklenir. Ancak TDD ve DevOps söz konusu olunca daha bir çok test tekniği vardır. Smoke Testing, Penetration Testing, Stress Testing, A/B testing, Fuzz Testing ve Boundary Testing gibi. [Daha fazla]

Mocha'nızı Node.js ile Alır mıydınız?

Bu yazımızda Node.js kodlarımızı test etmek için kullanabileceğimiz Mocha ve Should çatılarına değiniyoruz. Çok basit bir node.js fonksiyonelliğini test edereken behaviour driven development(BDD) odaklı yaklaşıma da çok çok yüzeysel anlamda vurguda bulunuyoruz. Should çatısını kullanırken kendi özel assertion fonksiyonlarımızı nasıl yazabileceğimize de kısaca bakıyoruz. Özetle test yazmanın nasıl keyifli hale getirildiğine bakıyoruz. [Daha fazla]

GoLang - Unit Test Yazmak

Aranızda birim test(Unit Test) yazmayan hala var mı? diyerek konuya giriş yapmak istiyorum. Yazdığımız atomik fonksiyonelliklerin taşınan ortamlarda başımızı ağrıtmasını istemiyorsak birim testleri mutlaka yazmalıyız. Belki birim testler uygulama geliştirme süresini uzatabilirler ancak uzun vadede kalp krizi geçirme riskini de azaltırlar. Üstelik test senaryoları sayesinde gerçekten ne yapmak istediğimizin farkında olarak da hareket edebiliriz. Eğer test güdümlü yaklaşımla ilerliyorsak bilinçli olarak yaptırılan hata sonrası kodun çalışır hale getirilmesi ve iyileştirilmesi(Refactoring) de önemli kazanımlarımızdır. [Daha fazla]

Ruby Kod Parçacıkları 25 - Unit Test Yazmak

İyi yazılım geliştirmenin olmazsa olmaz parçalarından birisi de birim testleridir(Unit Tests) Tahmin edileceği üzere Test Driven Development denildiğinde(aklımızda hemen Red Green Blue - Fail, Fix, Refactoring oluşmalı) birim testleri ön plana çıkmaktadır. Pek çok programlama ortamında birim testler için hazır kütüphaneler yer alır. Ruby dilinde ise standart kütüpanede yer alan Test::Unit modülü kullanılmaktadır. Testlere dahil edilecek savlar(assert diyelim) oldukça geniştir. assert, assert_not_equal, assert_nil, assert_respond_to, assert_raise ve benzeri fonksiyonellikler söz konusudur (Kullanılabilecek savların listesine şuradan bakabilirsiniz) Aşağıdaki kod parçasında basit bir test düzeneğine yer verilmiştir. [Daha fazla]