Bir loglama middleware'i, uygulamanızın ürettiği yanıtı değiştirebilir mi? Çoğumuzun cevabı muhtemelen "hayır" olur. Biz de öyle düşünüyorduk. Şirketimizde servislerimizi .NET 11'e taşımak için gerekli geliştirmeleri yaptık. Happy path senaryolarını test ettiğimizde herhangi bir problem görmedik. Ardından servis genelinde bir sorun olup olmadığını anlamak için
Merhabalar, 24 Mayıs 2025 tarihinde Dotnet Konferansı'nda MediatR != CQRS isminde bir sunum verdim. Sunumun konularını kısaca şöyle özetleyebilirim: * What is MediatR * What is CQRS * Why MediatR != CQRS * When to use CQRS * When to use MediatR * When not to use MediatR * What are disadvantages of CQRS * How to solve
Merhabalar 👋 Bu yazımda .NET Core'da feature'ları yönetebildiğimiz kütüphane olan FeatureManagement kütüphanesinden ve feature ayarlarımızı saklayabileceğimiz farklı alanlardan bahsedeceğim. Bazen geliştirdiğimiz özellikleri canlı ortama almışken o özelliklerin kapalı gelmesini ve zamanı geldiği zaman açmak isteyebiliriz. Bu tip operasyonları yönetmek için .NET Core'da FeatureManagement kütüphanesinden yararlanıyoruz.
Merhabalar. Bu yazımda geliştirmiş olduğumuz uygulamaların iletişime geçtiği API'ların dönüşlerinin (response) nasıl mocklanacağından bahsedeceğim. Şöyle bir senaryoyu düşünelim. Bir Front-End uygulaması üzerinden (React, Vue veya Angular ile geliştirilmiş) bir API uygulamasına istek atıyoruz. Front-End uygulamamızın testlerini yazarken API uygulamasının da ayakta ve istediğimiz cevapları vermesini beklemekteyiz.
15 Mayıs 2020 günü dotnet istanbul'da .NET Core ile RESTful API Design isimli online bir etkinlik gerçekleştirdik. Kısacası sunumda bahsettiğim konular şu şekilde; * API standartları * Kullanılması gereken HTTP metodları * Hangi HTTP durum kodu (Status Code) nerede kullanılır * Güvenlik standartları * Versiyonlama nasıl yapılır * API test için kullanabileceğiniz araçlar * API
Önceki yazılarımda Puppeteer ve Jest ile nasıl E2E testlerinin yazılacağından bahsetmiştim. Bu yazımda ise QA Wolf'u kullanarak hızlıca Puppeteer testlerinin yazılacağından bahsedeceğim. QA Wolf, testlerinizi ekrana gelen Chromium penceresi üzerinden aksiyonlar alarak otomatik olarak test dosyalarını oluşturan bir araçtır. Kendisi arkaplanda Puppeteer ve Jest'i kullanarak testleri
Merhabalar. Önceki 2 yazımda Puppeteer'a giriş yapıp, setup ve teardown durumlarını incelemiştik. Puppeteer ile bir test yazarken bazı durumlarda web uygulamasına giriş yapılması gerekebilir ve giriş bilgilerinin (örneğin cookie veya token bilgileri) bir yerde saklanıp kullanılması gerekebilir. Bu yazımda ben bir web sitesine login olup ilgili cookie değerlerini
Merhabalar. Bir önceki yazımda Puppeteer ve Jest'in kurulumu ve testlerin nasıl yazılacağından bahsetmiştim. Bu yazımda ise birçok test aracında da bulunan Setup ve Teardown yapılarının Puppeteer'da nasıl yapılabileceğinden bahsedeceğim. Öncelikle Setup, Teardown ve Test Environment kavramlarından bahsedelim. Setup, tüm testler yazılmadan önce yapılması gereken işlerin yapıldığı
Bu yazımda Puppeteer ve Jest araçlarını kullanarak nasıl E2E (End-to-End) test yazılacağından bahsedeceğim. Puppeteer, Headless Chrome çözümlerinden biridir. Puppeteer'ı kullanarak Chrome veya Chromium tabanlı herhangi bir tarayıcı kullanarak sağlanan API'lar vasıtasıyla tarayıcıyı kontrol edebilirsiniz. Örneğin DOM'u manipüle etme, sayfa boyutunu değiştirerek tarayıcının
.NET Core 3.0 ile beraber Worker isminde yeni bir proje şablonu geldi. Bu proje şablonu sayesinde Windows ve Linux servisleri oluşturabiliyoruz. Konuyu daha da pekiştirebilmek için örnek bir uygulama üzerinden devam edelim. Yapacağımız bu uygulama saniyede bir bulunduğu zamanı log olarak yazacaktır. Şimdi aşağıdaki komutu terminale yazarak yeni bir
Code Coverage, yazılmış olan testin kodunuzun ne kadarını kapsadığını belirten bir ölçümdür. Bu ölçüm sayesinde kodunuzda testi yazılmamış kısımlar bulunuyorsa analizini yaparak ilgili satırların veya bölümlerinin testini yazmaya karar verebilirsiniz. Mümkün olduğunca code coverage yüzdesinin yüksek olmasına önem verilmelidir. .NET Core'da dahili olarak code coverage raporunu oluşturabilecek bir
ASP.NET Core'da oluşturuşmuş bir Web API'ın dökümantasyonu için Swagger ve Swagger UI kullandığınızda varsayılan olarak güvenlik ile ilgili HTTP header'larını arayüz üzerinden girememektesiniz. Örnek vermek gerekirse geliştirmiş olduğunuz API güvenliğini sağlayabilmek için Client-Id ve Client-Secret isminde iki tane HTTP header'