Murat Genc

Özellikle I/O yoğun işlemler veya işlemlerin paralel olarak yürütülmesi gereken durumlar için önemlidir. Asenkron testler, testlerin tamamlanmasını beklemek için Task veya Task<T> döndürürler. Örneğin, bir HTTP isteği gönderme veya bir veritabanı sorgusu çalıştırma gibi bir işlemi test etmek isteyebilirsiniz. Bu tür işlemler genellikle asenkron olarak gerçekleştirilir, çünkü bu işlemler genellikle bloklama yapar ve programın diğer işlemlerini engeller. Asenkron test desteğini eklemek için, TestRunner‘ın asenkron test metotlarını tanıyabilmesi ve doğru bir şekilde çalıştırabilmesi gerekir.

Continue reading 

Testlerin daha iyi organize edilmesine ve belirli test gruplarının seçilerek çalıştırılabilmesini istesek ne yaparız. Testleri belirli grup veya kategori halinde düzenlesek? Bu özelliği eklemek için, bir TestSuiteAttribute oluşturabiliriz. Bu attribute, bir test sınıfına veya test metoduna uygulanabilir. Ayrıca, TestRunner‘ı güncelleyerek, belirli bir test grubu için testleri çalıştırabiliriz. using System; using System.Reflection; using System.Collections.Generic; using System.Linq; using System.Threading.Tasks; // ... public class TestSuiteAttribute : Attribute { public string SuiteName { get; } public TestSuiteAttribute(string suiteName) { SuiteName = suiteName; } } public static class TestRunner { // .

Continue reading 

Genellikle bir test framework’ünde “Parameterized Tests” veya “Data-Driven Tests” adı verilen bir özellik kullanılır. Bu özellik, bir test metodunun farklı veri setleriyle birden çok kez çalıştırılmasını sağlar. Bizde bu özelliği ekleyelim. Aşağıda, TestCase adında bir attribute ve TestRunner‘da bu attribute’u işleyecek kodu tanımlayalım, bu sayede TestRunner ıda refactor edelim. using System; using System.Reflection; using System.Collections.Generic; using System.Linq; using System.Threading.Tasks; // ... public class TestCaseAttribute : Attribute { public object[] Parameters { get; } public TestCaseAttribute(params object[] parameters) { Parameters = parameters; } } public static class TestRunner { public static async Task RunTestsAsync<T>() { var testClassInstance = Activator.

Continue reading 

Assert sınıfına HasElements işlevini ekleyelim. Bu işlev, bir koleksiyonun belirli öğelere sahip olup olmadığını kontrol eder. using System; using System.Collections.Generic; using System.Linq; using System.Threading; // ... önceki exception sınıfları ... public class AssertHasElementsFailedException : AssertFailedException { public AssertHasElementsFailedException(IEnumerable<object> missingElements) : base($"Expected collection to contain {string.Join(", ", missingElements)}, but it did not.") { } } public static class Assert { // ... önceki metodlar ... public static void HasElements<T>(IEnumerable<T> collection, params T[] elements) { var missingElements = elements.

Continue reading 

Şimdi, IsSameAs ve IsNotSameAs işlevlerini ekleyelim. Bu işlevler, iki nesnenin aynı referansa sahip olup olmadığını kontrol eder. using System; using System.Collections.Generic; using System.Linq; using System.Threading; // ... önceki exception sınıfları ... public class AssertIsSameAsFailedException : AssertFailedException { public AssertIsSameAsFailedException(object value, object other) : base($"Expected {value} to be the same as {other}, but it was not.") { } } public class AssertIsNotSameAsFailedException : AssertFailedException { public AssertIsNotSameAsFailedException(object value, object other) : base($"Expected {value} to not be the same as {other}, but it was.

Continue reading 

Bu sefer Assert sınıfına IsEmpty ve IsNotEmpty işlevlerini ekleyelim. Bu işlevler sayesinde, bir koleksiyonun boş olup olmadığını kontrol edebiliriz. using System; using System.Collections.Generic; using System.Linq; using System.Threading; // ... önceki exception sınıfları ... public class AssertIsEmptyFailedException : AssertFailedException { public AssertIsEmptyFailedException() : base("Expected collection to be empty, but it was not.") { } } public class AssertIsNotEmptyFailedException : AssertFailedException { public AssertIsNotEmptyFailedException() : base("Expected collection to not be empty, but it was.

Continue reading 

Evet, Assert sınıfımıza IsInstanceOfType ve IsNotInstanceOfType işlevlerini ekleyelim. Bu işlevler, bir nesnenin belirli bir türden olup olmadığını kontrol eder. Ayrıca, her biri için özel hata türleri oluşturalım. using System; using System.Collections.Generic; using System.Linq; using System.Threading; // ... önceki exception sınıfları ... public class AssertIsInstanceOfTypeFailedException : AssertFailedException { public AssertIsInstanceOfTypeFailedException(object value, Type expectedType) : base($"Expected {value} to be instance of type {expectedType}, but it was not.") { } } public class AssertIsNotInstanceOfTypeFailedException : AssertFailedException { public AssertIsNotInstanceOfTypeFailedException(object value, Type expectedType) : base($"Expected {value} not to be instance of type {expectedType}, but it was.

Continue reading 

Bu sefer, ‘Assert’ sınıfına ‘LessThan’, ‘LessThanOrEqual’, ‘GreaterThan’, ve ‘GreaterThanOrEqual’ işlevleri ekleyelim. Bu işlevler sayesinde, iki değerin birbirine göre sıralamasını kontrol edebiliriz. Ayrıca, her biri için özel hata türleri oluşturalım. using System; using System.Collections.Generic; using System.Linq; using System.Threading; // ... önceki exception sınıfları ... public class AssertLessThanFailedException : AssertFailedException { public AssertLessThanFailedException(object value, object boundary) : base($"Expected {value} to be less than {boundary}, but it was not.") { } } public class AssertLessThanOrEqualFailedException : AssertFailedException { public AssertLessThanOrEqualFailedException(object value, object boundary) : base($"Expected {value} to be less than or equal to {boundary}, but it was not.

Continue reading 

Assert sınıfını daha da geliştirelim. Şimdi, özel hata mesajları içeren Assert hata türleri ekleyelim. Bu, hataları daha iyi yönetmeyi ve test hatalarını daha iyi tanımlamayı sağlayacaktır. using System; using System.Collections.Generic; using System.Linq; using System.Threading; public class AssertFailedException : Exception { public AssertFailedException(string message) : base(message) { } } public class AssertEqualFailedException : AssertFailedException { public AssertEqualFailedException(object expected, object actual) : base($"Expected: {expected}, Actual: {actual}") { } } public class AssertNotEqualFailedException : AssertFailedException { public AssertNotEqualFailedException(object value) : base($"Unexpected value: {value}") { } } public class AssertTrueFailedException : AssertFailedException { public AssertTrueFailedException() : base("Expected condition to be true, but was false.

Continue reading 

Assert sınıfımıza daha fazla method ekleyelim. using System; namespace SimpleTestFramework { public class Assert { public static void Equal(object expected, object actual, string message = null) { if (!expected.Equals(actual)) { throw new Exception(message ?? $"Expected {expected}, but got {actual}"); } } public static void True(bool condition, string message = null) { if (!condition) { throw new Exception(message ?? "Expected condition to be true, but was false."); } } public static void False(bool condition, string message = null) { if (condition) { throw new Exception(message ?

Continue reading 

Basit test framework’ümüze birkaç özellik ekleyelim. SetUp ve TearDown metodları, bu metodlar, her test öncesi ve sonrası çalışır ve testler arasında tekrar eden kodu azaltmaya yardımcı olabilir. using System; namespace SimpleTestFramework { public class TestAttribute : Attribute { } public class SetUpAttribute : Attribute { } public class TearDownAttribute : Attribute { } public class Assert { public static void Equal(object expected, object actual) { if (!expected.Equals(actual)) { throw new Exception($"Test Failed: Expected {expected}, but got {actual}"); } } } public class TestRunner { public void RunTests<T>() where T : new() { var type = typeof(T); var instance = new T(); var setUpMethod = Array.

Continue reading 

Unit test yazarken genellikle NUnit veya XUnit gibi mevcut unit test framework’leri kullanılırız. Ancak, eğer basit bir unit test framework’ü kendimiz yazmak istersek, nasıl yaparız?. Ve başlayalım. Tek bir assert methodumuz ve runner ımızla başlangıcı yapalım. using System; namespace SimpleTestFramework { public class TestAttribute : Attribute { } public class Assert { public static void Equal(object expected, object actual) { if (!expected.Equals(actual)) { throw new Exception($"Test Failed: Expected {expected}, but got {actual}"); } } } public class TestRunner { public void RunTests<T>() where T : new() { var type = typeof(T); var instance = new T(); foreach (var method in type.

Continue reading 

Daha önce çalıştığımız reflection makalelerini kullanarak, .NET 6 ile AutoMapper benzeri bir yapıda mapping uygulamasını reflection ve IL emit kullanarak performanslı olacak şekilde yazalım. Mapping API’sini oluşturmak için, MyMappingLibrary projesine IMapper adında bir arayüz ve Mapper adında bir sınıf ekleyin. IMapper.cs public interface IMapper { TDestination Map<TSource, TDestination>(TSource source); void CreateMap<TSource, TDestination>(); } Mapper.cs using System; using System.Collections.Generic; using System.Reflection; using System.Reflection.Emit; public class Mapper : IMapper { private readonly Dictionary<(Type Source, Type Destination), Delegate> _mappingFunctions = new(); public TDestination Map<TSource, TDestination>(TSource source) { if (source == null) { throw new ArgumentNullException(nameof(source)); } var key = (typeof(TSource), typeof(TDestination)); if (!

Continue reading 

Veritabanları ile çalışırken, eşzamanlı transactionların doğru bir şekilde yönetilmesi ve veri bütünlüğünün korunması büyük önem taşır. LINQ (Language Integrated Query) ile veritabanı işlemlerinde transactionlar (transactions) kullanarak çakışmaların nasıl çözüleceği konusunda örnekler ve ve öneriler gösterilecektir. Transactionlar (Transactions) Nedir? Transactionlar, veritabanı üzerinde gerçekleştirilen bir dizi işlemi gruplayan ve bu işlemlerin tamamının başarılı bir şekilde tamamlanmasını veya hiçbirinin gerçekleştirilmemesini sağlayan bir yöntemdir. Transactionlar, veri bütünlüğünü korumak ve eşzamanlı işlemlerde çakışmaları çözmek için kullanılır.

Continue reading 

Reflection, .NET’te çalışma zamanında tür bilgilerini keşfetmek ve işlem yapmak için kullanılabilen güçlü bir özelliktir. Bu makalede, Reflection Emit ve dinamik kod oluşturma, ileri düzey kavramlar ve gerçek dünya örnekleri ve uygulamaları ele alacağız. Reflection Emit ve Dinamik Kod Oluşturma Reflection Emit, çalışma zamanında dinamik olarak yeni türler, yöntemler ve özellikler oluşturmanıza olanak tanır. Bu, türlerin yapılarını ve işlevselliğini derleme zamanında bilinmeyen durumlar için uyarlamaya yardımcı olabilir. AssemblyName assemblyName = new AssemblyName("MyDynamicAssembly"); AssemblyBuilder assemblyBuilder = AssemblyBuilder.

Continue reading 

Reflection, .NET’te çalışma zamanında tür bilgilerini keşfetmek ve işlem yapmak için kullanılabilen güçlü bir özelliktir. Bununla birlikte, Reflection’ın performans etkileri de göz önünde bulundurulmalıdır. Bu makalede, Reflection kullanımının performans etkilerini, performansı artırmak için önerileri ve yöntemleri ve Reflection yerine kullanılabilen alternatif teknolojileri ve uygulamaları ele alacağız. Reflection Kullanımının Performans Etkileri Reflection, çalışma zamanında tür bilgilerini ve metadataları almak için kullanıldığında performans sorunlarına neden olabilir. Özellikle büyük ve karmaşık projelerde Reflection, hafıza kullanımını ve işlem süresini artırarak performansı olumsuz yönde etkileyebilir.

Continue reading 

Reflection, çalışma zamanında extension metodlar ve özel durumlarla işlem yapmak için kullanılabilir. Bu makalede, Reflection ile extension metodları ve özel durumları nasıl kullanabileceğinizi inceleyeceğiz. Extension Metodlarla Çalışma Extension Metodları Bulma Belirli bir tür için extension metodları bulmak için, derlemedeki tüm türleri inceleyin ve ‘MethodInfo.IsDefined()’ ile ‘ExtensionAttribute’ kontrolünü kullanarak extension metodları filtreleyin. Type extendedType = typeof(MyClass); Assembly assembly = Assembly.GetExecutingAssembly(); var extensionMethods = assembly.GetTypes() .SelectMany(type => type.GetMethods(BindingFlags.Static | BindingFlags.Public | BindingFlags.

Continue reading 

Reflection, çalışma zamanında olaylar (events) ve delegelerle işlem yapmak için kullanılabilir. Bu makalede, Reflection ile olaylar ve delegeleri nasıl kullanabileceğinizi inceleyeceğiz. Olaylarla (Events) Çalışma Olayları Elde Etme Belirli bir türün olaylarını elde etmek için, ‘Type.GetEvent()’ ve ‘Type.GetEvents()’ metodlarını kullanabilirsiniz. Type myType = typeof(MyClass); EventInfo myEvent = myType.GetEvent("MyEvent"); EventInfo[] events = myType.GetEvents(); Olaylara Yöntemleri Bağlama (Event Handlers) Olaylara yöntemleri bağlamak için, ‘EventInfo.AddEventHandler()’ metodunu kullanın. MyClass instance = new MyClass(); MethodInfo handlerMethod = typeof(Program).

Continue reading 

Mikroservis mimarileri, modern uygulamaların ölçeklenebilirlik, esneklik ve performans gereksinimlerini karşılamak için giderek daha yaygın hale geliyor. CAP ve PACELC teoremleri, mikroservis mimarilerinin temel prensiplerini anlamak ve uygulamak için önemli kavramlardır. Bu makalede, CAP ve PACELC teoremlerinin mikroservis mimarilerinde nasıl kullanıldığına dair örnekler ve şekiller sunacağız. CAP Teoremi ve Mikroservisler CAP teoremi, dağıtık sistemlerde Tutarlılık (Consistency), Erişilebilirlik (Availability) ve Bölüm Toleransı (Partition Tolerance) özellikleri arasındaki dengeyi ele alır. Mikroservis mimarilerinde, bu özellikler aşağıdaki şekillerde kullanılır:

Continue reading 

Bilgisayar bilimi ve veri tabanı sistemleri alanında, CAP ve PACELC teoremleri dağıtık sistemlerin temel özelliklerini ele alır. Bu makalede, PACELC teoreminden bahsedecek ve ardından CAP teoremi ile karşılaştıracağız. PACELC Teoremi PACELC teoremi, CAP teoreminin bir genişlemesi olarak kabul edilir ve 2010 yılında Daniel Abadi tarafından öne sürülmüştür. PACELC, dağıtık sistemlerdeki işlemlerin, özellikle bölüm olmaması durumunda, hem tutarlılık (consistency) hem de gecikme (latency) arasındaki ilişkiye odaklanır. PACELC teoreminin adı, şu ifadeden oluşmaktadır: “Bölüm (Partition) oluştuğunda Tutarlılık (Consistency) veya Erişilebilirlik (Availability) seçilmeli ve Bölüm olmadığında ise Tutarlılık (Consistency) veya Gecikme (Latency) seçilmelidir.

Continue reading 