Umbraco API ile Kabul Testleri: TDD Pratiği

Umbraco projelerinizde sürekli değişen içerik modelleri ve yönetim gereksinimleriyle karşılaşıyor, yazdığınız kodun beklenen şekilde çalıştığından emin olmakta zorlanıyor musunuz? Bu makale, Umbraco’nun güçlü yönetim API’sini kullanarak Test Güdümlü Geliştirme (TDD) yaklaşımıyla kabul testleri yazmayı adım adım öğreterek yazılım kalitenizi artırmanıza yardımcı olacak.

Modern web projeleri, özellikle içerik yönetim sistemleri (CMS) üzerinde geliştirilenler, sürekli bir değişim ve evrim içindedir. Umbraco gibi esnek ve geliştirici dostu bir CMS ile çalışırken, özelleştirmeler, eklentiler ve yeni özellikler sıkça devreye alınır. Ancak bu dinamik yapı, beraberinde ciddi riskler de getirir: Yazılan kodun beklenen gibi çalışmaması, mevcut özelliklerin bozulması veya yeni eklenen bir fonksiyonun genel sistem kararlılığını etkilemesi gibi durumlarla sıkça karşılaşılabilir. Manuel test süreçleri zaman alıcıdır, hataya açıktır ve özellikle büyük projelerde sürdürülebilir değildir. Bu noktada, yazılım kalitesini baştan sona güvence altına alacak sağlam bir stratejiye ihtiyaç duyarız. İşte tam da burada Test Güdümlü Geliştirme (TDD) ve kabul testleri devreye giriyor.

TDD, geliştirme sürecini testlerin yönlendirdiği bir metodolojidir. Bir özelliği yazmadan önce, o özelliğin nasıl davranması gerektiğini tanımlayan bir test yazılır. Bu test başlangıçta başarısız olur (Red), ardından testin geçmesini sağlayacak minimum kod yazılır (Green) ve son olarak kod kalitesi iyileştirilir (Refactor). Bu döngü, yazılımın daha sağlam, bakımı daha kolay ve daha hatasız olmasını sağlar. Ancak TDD’nin bir adım ötesi vardır: Kabul testleri. Kabul testleri, son kullanıcının veya iş biriminin beklentilerini karşılayıp karşılamadığını doğrulamak için yazılır. Yani, bir özelliğin sadece teknik olarak doğru çalışıp çalışmadığını değil, aynı zamanda iş gereksinimlerine uygun olup olmadığını da kontrol eder. Umbraco yönetim API’si ile bu testleri yazmak, içerik oluşturma, güncelleme, silme ve diğer back-office işlemlerini programatik olarak doğrulamanıza olanak tanır. Böylece, hem geliştirme süreciniz hızlanır hem de projenizin genel kalitesi ve sürdürülebilirliği artırılır. Bu makale boyunca, bu kavramları Umbraco bağlamında nasıl uygulayacağımızı adım adım keşfedeceğiz. Unutmamak gerekir ki, manuel testler zamanla maliyetli hale gelirken, otomatik testler uzun vadede hem zaman hem de kaynak tasarrufu sağlar. Bu yüzden, Umbraco projelerinizde daha güvenli ve hızlı ilerlemek için bu yaklaşımları benimsemek kritik öneme sahiptir.

Temel Kavramlar: TDD, Kabul Testleri ve Umbraco Yönetim API’si Nedir?

Umbraco projelerimizde kaliteyi artırmak için kullanacağımız araçları ve metodolojiyi anlamak, başarılı bir uygulama için temel teşkil eder. Bu bölümde, test güdümlü geliştirme, kabul testleri ve Umbraco’nun sunduğu yönetim API’sinin ne anlama geldiğini ve neden bu kadar önemli olduklarını detaylıca inceleyeceğiz.

Test Güdümlü Geliştirme (TDD) Yaklaşımı: Neden Bu Kadar Popüler?

Test Güdümlü Geliştirme (TDD), yazılım geliştirmede devrim niteliğinde bir yaklaşımdır. Geleneksel olarak kod yazılır ve sonrasında test edilirken, TDD bu sıralamayı tersine çevirir. TDD, “Red-Green-Refactor” (Kırmızı-Yeşil-Yeniden Düzenle) adı verilen üç adımlı bir döngüde ilerler:

1. Red (Kırmızı): İlk olarak, henüz var olmayan bir özelliği tanımlayan, başarısız olacak bir otomatik test yazılır. Bu, geliştiricinin neyi başarması gerektiğini net bir şekilde anlamasına yardımcı olur ve yazılımın beklentilerini somutlaştırır.
2. Green (Yeşil): Yazılan testin geçmesini sağlayacak en basit kodu yazılır. Bu aşamada kodun kalitesi veya mükemmeliyeti ikinci plandadır; tek amaç testi geçirmektir.
3. Refactor (Yeniden Düzenle): Test başarıyla geçtikten sonra, kodun kalitesi, okunabilirliği, performansı ve sürdürülebilirliği iyileştirilir. Bu aşamada testlerin başarısız olmaması kritik öneme sahiptir, zira testler, yeniden düzenleme sırasında herhangi bir işlevselliğin bozulmadığının güvencesidir.

Bu döngü sürekli tekrarlandıkça, ortaya çıkan kodun daha temiz, daha anlaşılır, daha az bug içeren ve daha esnek olduğu görülür. TDD, aynı zamanda geliştiricilerin tasarımlarını iyileştirmelerine ve bağımlılıkları azaltmalarına yardımcı olan bir tasarım aracı olarak da işlev görür. Yazılan her test, aslında birer spesifikasyon görevi görür ve kodun “belgesini” oluşturur. Böylece, projenin büyüklüğü ne olursa olsun, yeni özellikler eklendiğinde veya mevcut kodda değişiklikler yapıldığında, testler bize bir güvenlik ağı sunar.

Kabul Testleri (Acceptance Tests) Nedir ve Neden Kullanılır?

Kabul testleri, yazılımın belirli iş gereksinimlerini veya kullanıcı hikayelerini karşılayıp karşılamadığını doğrulamak için tasarlanmış üst düzey testlerdir. Bu testler, genellikle müşteri veya ürün sahibi tarafından tanımlanan beklentilere dayanır ve sistemin “doğru şeyi yapıp yapmadığını” kontrol eder. Birim testleri bir metodun veya sınıfın tek bir küçük parçasının doğru çalıştığını doğrulamaya odaklanırken, entegrasyon testleri farklı modüllerin birbiriyle uyumlu çalıştığını kontrol ederken, kabul testleri tüm sistemin son kullanıcı perspektifinden beklenen işlevi yerine getirip getirmediğini doğrular.

Örneğin, bir Umbraco projesinde “Kullanıcı yeni bir blog yazısı oluşturabilmeli ve yayımlayabilmeli” şeklinde bir iş gereksinimi varsa, kabul testi bu senaryoyu baştan sona simüle eder. Bu, bir kullanıcının Umbraco back-office’ine giriş yapması, yeni bir içerik düğümü oluşturması, gerekli alanları doldurması ve yayımlaması gibi adımları içerebilir. Otomatik kabul testleri sayesinde, bu tür senaryolar sürekli olarak kontrol edilebilir, böylece yeni bir kod değişikliğinin mevcut işlevselliği bozup bozmadığı hızlıca tespit edilebilir. Bu testler, geliştirici ve iş birimi arasındaki iletişimi güçlendirir, beklenti farklılıklarını giderir ve nihayetinde daha memnun edici bir ürün ortaya çıkmasına yardımcı olur.

Umbraco Yönetim API’si (Management API) Bize Ne Sunuyor?

Umbraco Yönetim API’si, Umbraco 9 ve sonraki sürümlerinde sunulan, Umbraco back-office işlevselliğine programatik olarak erişim sağlayan güçlü bir RESTful API’dir. Bu API, geliştiricilere içerik düğümleri oluşturma, güncelleme, silme, medya öğeleri yönetimi, belge türleri üzerinde işlem yapma ve hatta kullanıcıları ve izinleri yönetme gibi bir dizi işlemi HTTP istekleri aracılığıyla gerçekleştirme imkanı sunar. Temelde, Umbraco back-office’inde bir editörün yapabileceği hemen hemen her şeyi kod aracılığıyla yapabileceğiniz anlamına gelir.

Bu API’nin varlığı, kabul testleri yazarken bize muazzam bir esneklik ve güç katar. Artık test senaryolarımızı, sanal bir tarayıcı otomasyonuna ihtiyaç duymadan doğrudan Umbraco’nun kalbiyle etkileşime geçerek oluşturabiliriz. Örneğin, yeni bir içerik türü altında otomatik olarak bir içerik düğümü oluşturup, ilgili alanları doldurup, hatta bir medya öğesi yükleyip bunu içerik düğümüne bağlayabilir ve ardından bu düğümün başarıyla yayımlandığını doğrulayabiliriz. Tüm bunlar, HTTP çağrıları ve JSON veri alışverişi üzerinden gerçekleşir. API, standart kimlik doğrulama mekanizmalarını (örn. JWT tabanlı OAuth) destekler, bu da güvenli bir şekilde etkileşim kurmanızı sağlar. Bu API sayesinde, Umbraco projeleriniz için yazdığınız özel iş mantıklarının veya entegrasyonların, Umbraco’nun çekirdek yönetim işlevleriyle uyumlu ve hatasız çalıştığını güvence altına alan kapsamlı testler oluşturabiliriz.

TDD ile Umbraco Yönetim API’sini Kullanarak Kabul Testleri Nasıl Yazılır?

Şimdi teoriden pratiğe geçme zamanı! Bu bölümde, TDD’nin Red-Green-Refactor döngüsünü takip ederek Umbraco Yönetim API’si ile nasıl kabul testi yazacağımızı adım adım inceleyeceğiz. Senaryo olarak, Umbraco’da yeni bir “Blog Yazısı” içerik düğümü oluşturma işlemini ele alacağız. Bu, Umbraco tabanlı projelerde en sık karşılaşılan yönetim görevlerinden biridir.

Ortam Kurulumu ve Gerekli Araçlar: Başlamak İçin Ne Lazım?

Başlamadan önce, test ortamımızı hazırlamamız gerekiyor. İşte ihtiyacınız olacaklar:

• .NET SDK: Umbraco ve test projeniz için uyumlu bir .NET SDK (tercihen .NET 7 veya 8).
• Umbraco Projesi: Yönetim API’sinin etkin olduğu çalışan bir Umbraco 9+ projesi. Bu projenin bir veritabanı bağlantısı olmalı ve back-office’e erişebiliyor olmalısınız. Ayrıca, Umbraco’da API anahtarı veya bir API kullanıcısı oluşturarak kimlik doğrulama için gerekli önlemleri almalısınız.
• Test Çerçevesi: xUnit veya NUnit gibi popüler bir .NET test çerçevesi. Bu makalede xUnit kullanacağız.
• Assertion Kütüphanesi: FluentAssertions, testlerinizi daha okunur hale getirmek için harika bir seçimdir.
• HTTP İstemcisi: .NET’in yerleşik HttpClient sınıfı, API çağrıları için yeterlidir.
• JSON Serileştirme/Deserileştirme: System.Text.Json (varsayılan) veya Newtonsoft.Json.

Test projemizi oluşturalım:

dotnet new xunit -n UmbracoAcceptanceTests
cd UmbracoAcceptanceTests
dotnet add package FluentAssertions

Ardından, test projenize Umbraco API'sine erişmek için gerekli konfigürasyonları eklemeniz gerekecektir. Bu genellikle bir appsettings.json dosyası oluşturarak ve Umbraco API URL'si, API anahtarı veya kullanıcı kimlik bilgileri gibi ayarları buraya ekleyerek yapılır. Örneğin:

{
  "UmbracoApi": {
    "BaseUrl": "https://localhost:44380/", // Kendi Umbraco URL'niz
    "ApiKey": "SüperGüvenliAnahtarınız" // Umbraco back-office'ten alınan API anahtarı
  }
}

Bu konfigürasyonu test projenize yüklemek için Microsoft.Extensions.Configuration paketlerini kullanabilirsiniz.

İlk Testimizi Yazma (RED Aşaması): Henüz Var Olmayan Bir Özelliği Test Etmek

TDD'nin ilk adımı, başarısız olacak bir test yazmaktır. Amacımız, yeni bir "Blog Yazısı" oluşturmak. Umbraco'da bu içerik türünün mevcut olduğunu varsayalım. İlk testimiz, bu işlemi gerçekleştirecek bir metodun henüz var olmadığını ve bu nedenle başarısız olacağını gösterecek:

using Xunit;
using FluentAssertions;
using System.Threading.Tasks;

namespace UmbracoAcceptanceTests
{
    public class ContentManagementTests
    {
        [Fact]
        public async Task YeniBlogYazisiOlusturma_BasariliOlmalı()
        {
            // Arrange: Henüz bir API istemcisi veya metodumuz yok.
            // Bu kısım daha sonra doldurulacak.

            // Act: Henüz mevcut olmayan bir metodu çağırma denemesi (simüle edelim)
            // Guid? contentId = await _umbracoApiService.CreateBlogEntry("İlk Blog Yazım", Guid.Parse("parentId"), "blogPost");

            // Assert: Testin başarısız olmasını bekliyoruz, çünkü henüz işlevsellik yok.
            // Örneğin, "Assert.True(false)" ile bilinçli bir hata fırlatabiliriz.
            Assert.True(false, "Test henüz implemente edilmedi ve başarısız olmalı.");

            // contentId.Should().NotBeNull(); // Bu da sonra gelecek
        }
    }
}

Bu testi çalıştırdığınızda, beklediğiniz gibi başarısız olacaktır. Bu "kırmızı" durum, bize ne geliştirmemiz gerektiğini açıkça gösterir: Umbraco API'si üzerinden bir blog yazısı oluşturacak bir mekanizma.

API İstemcisini Geliştirme (GREEN Aşaması): Testi Geçirmek İçin Minimum Kod

Şimdi "kırmızı" testi "yeşile" çevirmek için gerekli minimum kodu yazalım. Umbraco API'si ile etkileşime geçecek bir servis sınıfı oluşturacağız. Bu servis, HTTP istemcisini kullanarak içerik düğümü oluşturma isteği gönderecek.

İlk olarak, Umbraco API'sinden yanıt dönecek basit bir model tanımlayalım:

public class ContentCreateResponse
{
    public Guid Id { get; set; }
    // Diğer gerekli property'ler (örneğin Udi, Name) eklenebilir
}

Ardından, UmbracoApiService sınıfımızı oluşturalım:

using System.Net.Http;
using System.Net.Http.Json;
using System.Threading.Tasks;
using System;
using System.Collections.Generic;

namespace UmbracoAcceptanceTests
{
    public class UmbracoApiService
    {
        private readonly HttpClient _httpClient;
        private readonly string _apiKey;

        public UmbracoApiService(HttpClient httpClient, string umbracoApiKey)
        {
            _httpClient = httpClient;
            _apiKey = umbracoApiKey;
            _httpClient.DefaultRequestHeaders.Add("Umb-Api-Key", _apiKey); // API anahtarını ekle
            _httpClient.BaseAddress = new Uri("https://localhost:44380/"); // Kendi Umbraco URL'niz
        }

        public async Task CreateContentNode(string name, Guid parentId, string contentTypeAlias)
        {
            var requestBody = new
            {
                name = name,
                parentId = parentId,
                contentTypeAlias = contentTypeAlias,
                invariant = new {
                    // İçerik düğümüne özel alanları buraya ekleyebilirsiniz.
                    // Örneğin, bir blog yazısı için "title" ve "body" alanları.
                    // Bu örnekte sadece temel oluşturma işlemini gösteriyoruz.
                }
            };

            // Umbraco Management API'sinin içerik oluşturma endpoint'i
            var response = await _httpClient.PostAsJsonAsync("umbraco/management/api/v1/content", requestBody);

            response.EnsureSuccessStatusCode(); // HTTP 200-299 aralığında olmayan bir yanıt gelirse exception fırlatır

            var contentResponse = await response.Content.ReadFromJsonAsync();
            return contentResponse?.Id;
        }
    }
}

Şimdi test metodumuzu güncelleyelim:

using Xunit;
using FluentAssertions;
using System;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Extensions.Configuration; // Konfigürasyonu okumak için

namespace UmbracoAcceptanceTests
{
    public class ContentManagementTests
    {
        private readonly UmbracoApiService _umbracoApiService;
        private readonly Guid _parentBlogFolderId; // Blog yazılarının oluşturulacağı klasörün ID'si
        
        public ContentManagementTests()
        {
            // Konfigürasyonu yükle
            var configuration = new ConfigurationBuilder()
                .AddJsonFile("appsettings.json")
                .Build();

            var umbracoApiSettings = configuration.GetSection("UmbracoApi");
            var baseUrl = umbracoApiSettings["BaseUrl"];
            var apiKey = umbracoApiSettings["ApiKey"];

            var httpClient = new HttpClient { BaseAddress = new Uri(baseUrl) };
            _umbracoApiService = new UmbracoApiService(httpClient, apiKey);

            // Umbraco'da önceden tanımlanmış bir "Blog Klasörü" içeriğinin ID'si
            // Bu ID'yi Umbraco back-office'ten veya başka bir API çağrısıyla alabilirsiniz.
            _parentBlogFolderId = Guid.Parse("SİZİN_BLOG_KLASÖRÜ_GUID_ID'NİZ"); 
        }

        [Fact]
        public async Task YeniBlogYazisiOlusturma_BasariliOlmalı()
        {
            // Arrange
            string blogPostName = $"Test Blog Yazısı {Guid.NewGuid()}";
            string contentTypeAlias = "blogPost"; // Umbraco'daki içerik türü alias'ınız

            // Act
            Guid? contentId = await _umbracoApiService.CreateContentNode(blogPostName, _parentBlogFolderId, contentTypeAlias);

            // Assert
            contentId.Should().NotBeNull("Çünkü yeni bir blog yazısı başarılı bir şekilde oluşturulmalı.");
            contentId.Should().NotBe(Guid.Empty, "Oluşturulan içerik ID'si boş Guid olmamalı.");

            // Opsiyonel: Oluşturulan içeriği silme veya daha fazla doğrulama adımları
            // Örneğin: await _umbracoApiService.DeleteContentNode(contentId.Value);
        }
    }
}

Şimdi bu testi çalıştırdığınızda, API çağrısı başarılı olursa testiniz yeşil olacaktır. Tebrikler, TDD döngüsünün ilk RED-GREEN aşamasını tamamladınız!

Testi İyileştirme (REFACTOR Aşaması): Daha Okunabilir ve Bakımı Kolay Kod

Testimiz çalışıyor, ancak daha iyi hale getirebiliriz. Refactor aşamasında odaklanacağımız noktalar:

• Daha Okunabilir Assertions: FluentAssertions kütüphanesi ile daha akıcı ve anlamlı doğrulama ifadeleri yazabiliriz.
• Test Verileri Yönetimi: Testlerin birbirini etkilememesi ve tekrarlanabilir olması için test verilerini nasıl yöneteceğimiz.
• Yardımcı Metotlar: Tekrarlayan kodları yardımcı metotlara veya bir test fixture'a taşımak.

Yukarıdaki kod zaten FluentAssertions kullanıyor ve oldukça okunabilir durumda. Test verileri yönetimi için, her testten sonra oluşturulan içeriği temizlemek iyi bir pratik olabilir. Bunun için UmbracoApiService sınıfına bir silme metodu ekleyebiliriz:

// UmbracoApiService sınıfına eklenecek metot
public async Task DeleteContentNode(Guid contentId)
{
    var response = await _httpClient.DeleteAsync($"umbraco/management/api/v1/content/{contentId}");
    return response.IsSuccessStatusCode;
}

Ve test metodumuzda bunu kullanalım:

// ContentManagementTests sınıfında, test metodunun sonunda veya bir IDisposable implementasyonunda
// [Fact] metodunun içinde kullanabiliriz. XUnit'te IDisposable daha temiz bir yol sunar.

public class ContentManagementTests : IDisposable
{
    // ... (önceki kodlar)
    private readonly List _createdContentIds = new List();

    public async Task YeniBlogYazisiOlusturma_BasariliOlmalı()
    {
        // ... (Act aşaması)
        Guid? contentId = await _umbracoApiService.CreateContentNode(blogPostName, _parentBlogFolderId, contentTypeAlias);
        contentId.Should().NotBeNull();
        _createdContentIds.Add(contentId.Value); // Oluşturulan ID'yi listeye ekle

        // ... (Assert aşaması)
    }

    // IDisposable arayüzünün Dispose metodunu implemente ederek test sonrası temizlik yapalım
    public void Dispose()
    {
        foreach (var id in _createdContentIds)
        {
            _umbracoApiService.DeleteContentNode(id).GetAwaiter().GetResult(); // Senkron çağrı için GetResult kullanıldı
        }
    }
}

Bu yaklaşım, her testin kendi oluşturduğu veriyi temizlemesini sağlayarak testlerin izole ve tekrarlanabilir olmasını garanti eder. Bu, TDD'nin Refactor aşamasında kodun değil, test altyapısının iyileştirilmesine bir örnektir.

Medya Yükleme Senaryosu (Vaka Analizi): Daha Karmaşık Bir API Etkileşimi

Umbraco'da içerik oluşturmak kadar yaygın bir diğer senaryo da medya yüklemektir. Umbraco Yönetim API'si üzerinden bir görseli nasıl yükleyeceğimize dair bir örnekle daha karmaşık bir API etkileşimini görelim. Bu senaryo, MultipartFormDataContent kullanımı gerektirir.

Önce UmbracoApiService sınıfımıza medya yükleme metodunu ekleyelim:

// UmbracoApiService sınıfına eklenecek metot
public async Task UploadMedia(string fileName, byte[] fileBytes, Guid parentId, string contentTypeAlias = "Image")
{
    using var formData = new MultipartFormDataContent();
    var fileContent = new ByteArrayContent(fileBytes);
    fileContent.Headers.Add("Content-Type", "image/jpeg"); // Veya uygun mime tipi

    formData.Add(fileContent, "file", fileName);
    formData.Add(new StringContent(parentId.ToString()), "parentId");
    formData.Add(new StringContent(contentTypeAlias), "contentTypeAlias");

    // Umbraco Management API'sinin medya yükleme endpoint'i
    var response = await _httpClient.PostAsync("umbraco/management/api/v1/media/file", formData);
    
    response.EnsureSuccessStatusCode();

    var mediaResponse = await response.Content.ReadFromJsonAsync(); // Aynı response modelini kullanabiliriz
    return mediaResponse?.Id;
}

Şimdi de bu metodu test edecek bir kabul testi yazalım:

using Xunit;
using FluentAssertions;
using System;
using System.IO;
using System.Threading.Tasks;

// ... (Diğer using'ler ve sınıf tanımı)

public class ContentManagementTests : IDisposable
{
    // ... (Önceki tanımlamalar)
    private readonly List _createdMediaIds = new List();
    private readonly Guid _parentMediaFolderId = Guid.Parse("SİZİN_MEDYA_KLASÖRÜ_GUID_ID'NİZ"); // Medya klasörünün ID'si

    [Fact]
    public async Task YeniMedyaYukleme_BasariliOlmalı()
    {
        // Arrange
        string fileName = $"test-gorsel-{Guid.NewGuid()}.jpg";
        // Gerçek bir resim dosyası içeriği (örneğin, 1x1 piksel boş bir JPEG)
        // Ya da test için basit bir byte dizisi oluşturabiliriz.
        byte[] fileBytes = await File.ReadAllBytesAsync("test-image.jpg"); // Projenize küçük bir test resmi ekleyin

        // Act
        Guid? mediaId = await _umbracoApiService.UploadMedia(fileName, fileBytes, _parentMediaFolderId);

        // Assert
        mediaId.Should().NotBeNull("Çünkü yeni bir medya öğesi başarılı bir şekilde yüklenmeli.");
        _createdMediaIds.Add(mediaId.Value);

        // Opsiyonel: Yüklenen medyanın URL'sini veya diğer özelliklerini kontrol etmek
        // Bunun için Umbraco API'sinin medya alma endpoint'ini kullanmak gerekir.
    }

    // Dispose metodunu güncelle
    public void Dispose()
    {
        foreach (var id in _createdContentIds)
        {
            _umbracoApiService.DeleteContentNode(id).GetAwaiter().GetResult();
        }
        foreach (var id in _createdMediaIds)
        {
            _umbracoApiService.DeleteContentNode(id).GetAwaiter().GetResult(); // Medya için de aynı silme endpoint'i kullanılabilir
        }
    }
}

Bu vaka analizi, Umbraco Yönetim API'sinin farklı endpoint'leriyle nasıl etkileşime geçileceğini ve TDD prensiplerini daha karmaşık senaryolara nasıl uygulayacağınızı göstermektedir. Her test, bağımsız ve tekrarlanabilir olmalı, ve her test kendi ortamını hazırlayıp kendi yarattığı veriyi temizlemelidir. Bu, sağlam ve güvenilir bir kabul testi altyapısı oluşturmanın anahtarıdır.

İleri Düzey TDD Pratikleri ve Optimizasyonlar

Temel kabul testleri yazmayı öğrendik, şimdi bu bilgileri bir adım öteye taşıyarak daha güçlü, esnek ve verimli test stratejileri geliştirelim. Deneyimli geliştiriciler için kabul testlerini daha da optimize edecek ipuçları ve püf noktaları bu bölümde yer alıyor.

Test Verisi Yönetimi: Ortamı Kirletmeden Test Etmek

Otomatik kabul testlerinin en büyük zorluklarından biri, test ortamındaki verileri yönetmektir. Her testin birbirinden bağımsız olması ve bir önceki testin bıraktığı veriden etkilenmemesi gerekir. Yukarıdaki IDisposable örneğimiz bir başlangıçtır, ancak daha gelişmiş stratejiler de mevcuttur:

• Test Veritabanı Resetleme: Her test süiti veya her test çalışması başlamadan önce Umbraco veritabanının belirli bir "temiz" duruma getirilmesi. Bu genellikle bir veritabanı yedeğinin geri yüklenmesi veya tüm tabloların boşaltılıp seed verilerinin yeniden eklenmesiyle yapılır. Bu yöntem daha yavaş olabilir ancak en güvenilir temizlik sağlar.
• API Destekli Temizleme: Umbraco Yönetim API'si üzerinden oluşturulan içeriği veya medyayı test bittikten sonra silmek. Yukarıdaki Dispose metodumuz bu stratejinin bir örneğidir. Tüm API işlemlerini kapsayan bir temizlik mekanizması kurmak önemlidir.
• Test Ortamı İzolasyonu: Her testin kendi Umbraco örneği (örneğin Docker konteynerleri kullanarak) üzerinde çalışması. Bu, en yüksek izolasyonu sağlar ancak kaynak tüketimi ve kurulum karmaşıklığı açısından maliyetli olabilir.

Seçilen strateji, projenizin büyüklüğüne, bütçesine ve testlerin çalışma sıklığına göre değişebilir. Önemli olan, testlerin deterministik olmasını sağlamaktır; yani her çalıştırıldığında aynı sonucu vermesi.

Performans Optimizasyonu: Hızlı Geri Bildirim Döngüleri

Kabul testleri genellikle birim testlerinden daha yavaş çalışır çünkü gerçek bir sistemle (Umbraco ve veritabanı) etkileşime girerler. Ancak TDD'nin temel prensiplerinden biri hızlı geri bildirimdir. Bu nedenle kabul testlerinin performansını optimize etmek kritik öneme sahiptir:

• Paralel Test Çalıştırma: Test çerçevelerinin (xUnit, NUnit) paralel test çalıştırma özelliklerini kullanarak testleri eş zamanlı çalıştırmak. Bu, test süresini önemli ölçüde kısaltabilir. Ancak, testler arasında veri çakışmaları olmaması için dikkatli olunmalıdır.
• Gereksiz API Çağrılarından Kaçınma: Eğer bir test sadece bir içeriğin varlığını kontrol ediyorsa, içeriği yeniden oluşturmak yerine var olan bir statik içeriği kullanmayı düşünebilirsiniz (temizlik sonrası geri yükleme yapılıyorsa). Ancak bu, test izolasyonunu bozabilir, dikkatli dengelemek gerekir.
• Önyükleme (Bootstrap) Optimizasyonu: Umbraco uygulamasının testler başlamadan önce sadece bir kez başlatılması ve testler arasında yeniden başlatılmaması. Bu, özellikle CI/CD ortamlarında test süresini kısaltır.

Güvenlik Testleri: Yetkilendirme ve Kimlik Doğrulama Senaryoları

Umbraco Yönetim API'si, içerik yönetiminin kalbinde yer aldığından, güvenlik testleri büyük önem taşır. Kabul testleri, kullanıcıların doğru yetkilere sahip olup olmadığını ve yetkisiz erişim denemelerinin engellendiğini doğrulamak için kullanılabilir:

• Başarısız Kimlik Doğrulama: Geçersiz API anahtarı veya kimlik bilgileriyle yapılan çağrıların 401 Unauthorized hatası döndürdüğünü test etmek.
• Yetkilendirme Testleri: Belirli bir kullanıcının veya API anahtarının sadece belirli içerik türlerini veya yönetim fonksiyonlarını kullanabildiğini doğrulamak. Örneğin, bir yazarın "Ayarlar" bölümündeki belge türlerini değiştirememesi.
• Veri Erişimi: Bir kullanıcının sadece kendi yetki alanı içindeki verilere erişebildiğini test etmek.

[Fact]
public async Task GecersizApiKeyIleIcerikOlusturma_YetkilendirmeHatasiVermeli()
{
    // Arrange
    var httpClient = new HttpClient { BaseAddress = new Uri("https://localhost:44380/") };
    var unauthorizedApiService = new UmbracoApiService(httpClient, "GecersizAnahtar");

    // Act
    var exception = await Record.ExceptionAsync(() => unauthorizedApiService.CreateContentNode("Hatalı Test", Guid.NewGuid(), "blogPost"));

    // Assert
    exception.Should().BeOfType();
    // HTTP durum kodu 401 (Unauthorized) veya 403 (Forbidden) olduğunu kontrol et
    ((HttpRequestException)exception).StatusCode.Should().Be(System.Net.HttpStatusCode.Unauthorized);
}

Hata İşleme Testleri: Beklenmeyen Durumlara Hazırlık

Sadece başarılı senaryoları test etmek yeterli değildir. API'nin beklenen hatalara (örn. 400 Bad Request, 404 Not Found, 500 Internal Server Error) nasıl yanıt verdiğini de test etmeliyiz. Bu, uygulamanızın beklenmedik durumlara karşı daha dayanıklı olmasını sağlar.

• Geçersiz Giriş Verileri: Bir içerik düğümü oluştururken zorunlu bir alanı boş bırakmak gibi geçersiz verilerle API'ye istek gönderildiğinde 400 Bad Request hatası döndürüldüğünü doğrulamak.
• Mevcut Olmayan Kaynak: Var olmayan bir içerik ID'si ile silme veya güncelleme işlemi yapıldığında 404 Not Found hatası döndürüldüğünü test etmek.

Mobil Uyumlu Testler İçin İpuçları (API Yanıtı Perspektifinden)

Backend API testleri doğrudan mobil uyumlu UI ile ilgili olmasa da, API'nin mobil uygulamalar tarafından nasıl tüketileceğini düşünmek önemlidir. Mobil cihazlar genellikle daha kısıtlı bant genişliği ve daha küçük ekran boyutlarına sahiptir. Bu nedenle:

• Yanıt Boyutları: API yanıtlarının mobil uygulamalar için gereksiz yere büyük olup olmadığını kontrol edin. Aşırı veri gönderimi mobil cihazlarda performansı olumsuz etkileyebilir. Test senaryolarınızda, API yanıtının belirli bir boyutu aşmadığını veya yalnızca gerekli alanları içerdiğini doğrulayabilirsiniz.
• Hata Mesajları: Mobil uygulamaların kullanıcıya dostu hata mesajları gösterebilmesi için API'nin anlaşılır ve yapılandırılmış hata yanıtları döndürdüğünü test edin.
• Kullanım Kolaylığı: Mobil geliştiricilerin API'yi kolayca entegre edebilmesi için API tasarımının ve yanıtlarının tutarlı ve öngörülebilir olduğunu doğrulayın.

HTML çıktısında doğrudan medya sorguları sağlamak backend testleriyle ilgili olmasa da, eğer test raporları veya API dokümantasyonu web arayüzünde sunuluyorsa, bu durumda responsive tasarım önemlidir:

  

    

      
Test Adı
      
Durum
      
Süre (ms)
    
  
  

    

      
YeniBlogYazisiOlusturma
      
Başarılı
      
125
    
    

      
YeniMedyaYukleme
      
Başarılı
      
210
    
  

Bu ileri düzey pratikler, Umbraco projelerinizde TDD ve kabul testlerinin potansiyelini tam olarak kullanmanıza yardımcı olacaktır. Kod kalitesini artırırken, aynı zamanda güvenliği, performansı ve sürdürülebilirliği de göz önünde bulundurmak önemlidir.

Sonuç: Umbraco Projelerinizde TDD ve Kabul Testlerinin Değeri

Bu makale boyunca, Umbraco'nun yönetim API'sini kullanarak TDD prensipleriyle kabul testleri yazmanın ne kadar değerli olduğunu detaylıca ele aldık. Geliştirme sürecini testlerin yönlendirdiği TDD yaklaşımı, sadece kod kalitesini artırmakla kalmaz, aynı zamanda işlevselliğin iş gereksinimlerine uygunluğunu da güvence altına alır. Kabul testleri, son kullanıcının beklentilerini karşılayıp karşılamadığımızı doğrulamak için kritik bir köprü görevi görürken, Umbraco Yönetim API'si bize bu testleri programatik olarak, verimli ve güvenilir bir şekilde uygulama gücünü sunar.

Red-Green-Refactor döngüsünü uygulayarak, ilk başta başarısız olan bir testle neyi başarmamız gerektiğini netleştirdik, ardından bu testi geçirecek minimum kodu yazdık ve son olarak kodumuzu ve test altyapımızı iyileştirdik. Medya yükleme gibi daha karmaşık senaryolarla, Umbraco API'sinin farklı yeteneklerini keşfettik. İleri düzey pratikler bölümünde ise test verisi yönetimi, performans optimizasyonu, güvenlik ve hata işleme testleri gibi konulara değinerek, kabul testlerinin kapsamını ve etkinliğini nasıl artırabileceğimizi gösterdik.

Unutmamak gerekir ki, otomatik kabul testleri yazmak başlangıçta ek zaman ve çaba gerektirse de, uzun vadede projenizin sürdürülebilirliğini, hatalara karşı direncini ve geliştirme hızını önemli ölçüde artırır. Geliştiricilerin yeni özellikler eklerken veya mevcut kodu refactor ederken daha güvende hissetmelerini sağlar, çünkü herhangi bir hatanın otomatik testler tarafından hızla yakalanacağını bilirler. Bu testler, aynı zamanda sürekli entegrasyon (CI) ve sürekli dağıtım (CD) süreçlerinin vazgeçilmez bir parçasıdır ve yazılımınızı her zaman dağıtıma hazır halde tutmanıza yardımcı olur. Umbraco projelerinizde kaliteyi ön planda tutmak ve daha güvenle ilerlemek için bu yaklaşımları benimsemenizi şiddetle tavsiye ederiz.

Sıkça Sorulan Sorular (SSS)

1. Kabul testleri performans üzerinde olumsuz etki yapar mı?

Evet, birim testlerine göre kabul testleri genellikle daha yavaş çalışır çünkü gerçek bir veritabanı ve API gibi dış sistemlerle etkileşime girerler. Ancak bu, TDD ve kabul testlerinden vazgeçmek için bir neden değildir. Paralel test çalıştırma, test verisi önbellekleme ve temiz test ortamları gibi optimizasyon teknikleriyle performans etkisi minimize edilebilir. Önemli olan, testlerden elde edilen güvenin, performans maliyetine değmesidir.

2. Umbraco yönetim API'sine kimlik doğrulama nasıl yapılır?

Umbraco Yönetim API'si, genellikle bir API anahtarı (API Key) veya JWT (JSON Web Token) tabanlı OAuth 2.0 akışlarıyla kimlik doğrulaması yapar. API anahtarı, Umbraco back-office'inden oluşturulabilen basit bir yöntemken, JWT daha gelişmiş güvenlik senaryoları için uygundur. Test ortamında, genellikle API anahtarı yeterli olabilirken, üretim ortamına yakın testlerde daha kapsamlı bir kimlik doğrulama süreci gerekebilir.

3. Bu testleri lokalde mi yoksa CI/CD'de mi çalıştırmalıyız?

Her iki yerde de çalıştırmalısınız. Lokal ortamda, geliştiriciler yeni kod yazarken veya mevcut kodu değiştirirken anında geri bildirim almalıdır. CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) ortamında ise, her kod değişikliğinde tüm test süiti otomatik olarak çalıştırılmalı ve herhangi bir regresyon veya hata durumunda geliştirme ekibine uyarı verilmelidir. Bu, yazılımın sürekli olarak dağıtıma hazır olmasını sağlar.

4. Her değişiklikte tüm kabul testlerini çalıştırmak gerekli mi?

Küçük değişiklikler için, sadece ilgili testleri çalıştırmak daha hızlı geri bildirim sağlayabilir. Ancak kod birleştirme (merge) öncesinde veya dağıtım öncesinde tüm kabul testlerini çalıştırmak, sistemin genel kararlılığını ve tüm işlevselliğin beklendiği gibi çalıştığını doğrulamak için kritik öneme sahiptir. Test süresini optimize etmek için, önemli olmayan veya çok uzun süren testleri daha az sıklıkta çalıştırabilirsiniz, ancak riskleri göz önünde bulundurmalısınız.

5. Umbraco'nun kendi test araçları var mı?

Umbraco'nun kendisi, çekirdek işlevselliği için kapsamlı birim ve entegrasyon testlerine sahiptir. Ancak bu makalede bahsettiğimiz kabul testleri, sizin özel Umbraco projenizin iş mantığını, belge türlerini, kompozisyonlarını ve diğer özelleştirmelerini test etmek için yazılır. Yani, Umbraco size bir API ve genişletilebilirlik noktaları sunarak kendi testlerinizi yazmanız için güçlü bir altyapı sağlar.