Ana içeriğe atla

Biraz C# ve biraz NUnit

Unit test:

Unit test yöntemi ile tasarım yapmak çok önemli çünkü akla gelebilecek ya da gelmeyecek birçok hatayı henüz büyük bir sistemi tasarlamadan tespit edebiliriz. NUnit aracının 2.4.X sürümünü kullanıyorum. NUnit, DUnit (Delphi Unit) sisteminden biraz daha farklı geliştirilmiş. Delphi test işlemlerini yapmak için birçok sınıf tasarlanmış ancak NUnit ortamında ise istenilen sınıf veya yöntem isimleri, test işlemleri için kullanılabilir. Test işleminin başarılı şekilde yapılabilmesi için önemli olan konu NUNit framework içinde yer alan attribute değerlerinin düzgün yerde kullanılmasıdır.

[TestFixture]
Test yapılacak sınıfın üzerinde tanımlanması gerekiyor. Bu tanımlama .Net assembly içindeki bu sınıf NUnit aracı tarafından tespit edilecek ve [Test] attribute değeri olan yöntemleri çalıştıracaktır.

[Test]
Delphi'de olduğu gibi yöntem isimlerini "Test" ile başlatmak gerekmiyor. NUnit aracı, ilgili sınıftaki tüm yöntemleri gezerken yöntemin public ve [Test] ile tanımlanmış olmasını kontrol etmektedir. Kontrolden geçen tüm yöntemler sırasıyla çalıştırılacaktır ve içindeki assert sınıfına ait yöntemleri tetikleyecektir.

[SetUp]
Test sınıf kodunun içinde her bir test yöntemi öncesinde yapılması gereken SetUp işlemi varsa bu attribute değeri tanımlanmalıdır.

(Setup değeri her bir test yönteminin öncesinde çalıştırılır.)

[TearDown]
Test sınıf kodunun içinde her bir test yöntemi sonrasında yapılması gereken kapanış işlemi varsa bu attribute değeri tanımlanmalıdır.

(TearDown değeri her bir test yönteminin sonrasında çalıştırılır.)

Örnek (Setup ve TearDown)
SetUp ve TearDown değerleri test işleminde unmanaged kodlarının olması durumunda kullanılabilir. Bir dosyadan satır, karakter, blok byte değerleri okunacaksa ve her bir özellik ayrı test yöntemleri içinde test edilecekse, SetUp yönteminde çalışacak dosya açılır, TearDown yönteminde ise kapatılır. Bu şekilde her üç test yöntemi içinde dosyanın açılıp/kapatılmasına ait kod tekrarının önüne geçilmiş olacaktır.



Bu blogdaki popüler yayınlar

Zeki sistemler

Zeki sistemler: Yapay zeka tekniklerini kullanan sistemlerdir. Sistem: Ortak bir amaca hizmet etmek için bir araya gelmiş bir ya da birden fazla elemanın uyum içinde çalışmasıdır. Melez Zeki Sistemler: Bir ya da birden fazla zeki sistemin bir araya gelmesi ve uyum için çalışmasıdır. Neden melez sisteme ihtiyaç var? Birçok iyi sistem bir araya getirilerek daha iyi sistemler oluşturulabilir. Uzman sistemlerdeki kararlılık, Genetik algoritmaların rastgeleliği ve True/False olarak ifade edilemeyen ancak yine de çözüm beklenen durumlarda bulanık sistemlerin kullanılarak "Melez Sistemlerin" tasarlanması birçok soruna çözüm sağlayabilir. Üst Zeki Sistemler: İnsan zekasına biraz daha yaklaşmayı hedefleyen ve şuan üzerinde düşündüğüm, çok daha fazla kaynak okumamı gerektiren sistemlerdir. Bu sistemlerle insan zekasına biraz daha yaklaşılması hedeflenebilir. Üst ( Meta ) Zeki Sistem (ÜZS) ile aynı anda birden fazla yapay zeka tekniği ya da alt sistemler kullanılabilir. Görüntü tanıma t...

Netle Yazılım | e-Defter Şematron Raporu | Sürüm 2.0.1.8.3

Netle Yazılım San. Tic. Ve A.Ş. e-Defter Şematron Raporu Ver 2.0.1.8.3 Açıklama Yasal e-defter dosyaları hazırlandıktan ve imzalandıktan sonra mutlaka XML şema ve Şematron denetimleri ile kontrol edilmelidir. Bu kontrol süreci sonrasında ortaya en az bir hata çıkması durumunda GİB tarafından e-defter dosyaları geçersiz sayılabilir.  Bu kontrollerin çok geniş ve uzun sürebilmesi nedeniyle kontrol süreçlerinde e-defter uyumlu yazılımlar kullanılmaktadır. Netle Yazılım tarafından geliştirilen "Netle-Defter" uygulaması bu kontrolleri fiş girişinde, döneme ilişkin parçalı ya da bütün defter oluşturmada ve GİB'e gönderim öncesinden yapmaktadır. Olası bir sorunda kullanıcı iş akış sistemi ile bilgilendirilerek hatanın giderilmesi beklenmektedir. Şematron denetimleri XML içine bütünleşik şekilde yazılmış ve bunların tam bir liste şeklinde dokümanı yoktu. Bu faydalı bilgileri liste haline getirdik ve 2018 / 3 dönemini esas olarak aşağıdaki açıkl...

Üst (Meta) modeli olan kavramları seviyorum; DocHuman ve RDL (Report Definition Language)

Dochuman süreç yönetim motoru bir veri kaynağını çok farklı biçimlere dönüştürebilir durumda. Bu özellik ile Dochuman veri modeli, RDL gösterim modeline dönüşebiliyor. Modeller arası dönüşümde, geliştirdiğimiz alt sistemler, veriyi bire-bir oranda dönüştürebilme yeteneğinde. Bir rapor var ve bu rapora ilişkin veri girişi yapılacaksa, rapor verileri expression olarak da ifade edilmiyosa geri dönüşüm kısa sürede mümkün olabilir. RDL içinde parametre, sabit değer, veri kaynaklı değer ve görsellerin özelleştirilmesi yeteneği DocHuman form tasarım sistemiyle birebir örtüşmektedir. Bir RDL barkod değeri ile DocHuman barkod değeri binlerce farklı satırlar sonucunda ortaya çıksa da; birbilerini anlayabilen iki sistemin uzlaşması noktasında işler daha kolaylaşacaktır. Bu tür gelişmiş özelliklere rağmen yazılıma her şeyi yapabilir misin diye sorulsa, "derlenmiş ve işlenmeye hazır halimde çok sıfır" var diyebilir.