Planning

In these days, I have been developing a small application for myself. All requirements/stories was on my mind. But, when I finished one task, I could not start to next one soon.

I made a list of task, wrote down then on a paper. And I made estimation and then a plan. As I finished the tasks, I marked them.

Actually, my estimations were not so good, and I could not follow the plan strictly. However, I gain much. First of all, I was able to see my progress.That is, I was able to see how much I finished, how much remained and what the next is. When I finised a task, then I soon start to next one instead of considering what I should do next.

In short, an aim and plan targeting the aim made me do my work faster.

Database Unit Testing in .NET and Rollback

In .Net, to rollback transactions after unit tests run, you can use Enterprise Services.

For more information, you can follow the link: http://weblogs.asp.net/rosherove/articles/dbunittesting.aspx

Session Based Working

In XP mail group, extremeprogramming@yahoogroups.com, while discussing the XP practice, '40-Hour-Week', Cory Foy mentioned about session based work:

We split the day into 4 "sessions". So we start with a 15 minute stand-up, have a 1.5 hour session, 20 min break, 1.5 hour session, lunch, 1.5 hour session, 20 min break, and a final 1.5 hour session.

That equates to about 6 hours of session time. However, because of the XP practices, and because everyone knows the schedules, they focus very hard on their sessions during that time, and we find ourselves amazingly productive. In fact, I'd say this is one of the more productive places I've been at."

I think it is a good idea. It makes developers more concentrated, focused and productive.
At the same time, this technique can be used for a personal sofware devolopment or any other kind of works.

NUnit ve .config Dosyası

Uygulamanız .config dosyası içeriyorsa ve NUnitle test yazmışsanız konfigürasyon işini testlerinize de bildirmelisiniz. Bunun için .config dosyasını test altına kopyalayın ve

1. Eger myProject.Tests.dll gibi direk bir test "assembly" yüklüyorsanız, dosyanın adı myProject.Tests.dll.config yapın.
2. Eger myProject.Tests.unit gibi direk bir NUnit projesi yüklüyorsanız, dosyanın adı myProject.Tests.config yapın.
3. Eger myProject.Tests.csproj yada myProject.Tests.sln gibi NUnit'in Visual Studio desteğini kullanarak bir VS proje yada çözümü yüklüyosanız, dosyanın adı myProject.Tests.config yapın.

Ve bu işin çalışıp çalışmadığını da test etmek için test projesi .config dosyasına;

<add key="testKey" value="I am a test key"/>

ekleyin.

Ve test olarak şunu yazın:

[Test]

public void CheckConfigFile()
{
Assert.AreEqual( "I am a test key", System.Configuration.ConfigurationSettings.AppSettings["testKey"] );

}

Başınız ağrısınız, testleriniz yeşil, kodunuz temiz olsun...

Kaynak : How NUnit Finds Config Files http://nunit.com/blogs/?p=9#respond

DBUnit de bir böcek

DBUnit ile bir data.xml' koyduğunuz verileri yüklerseniz ( FlatXmlDataSet kullanarak) dikkat edin. Veri dosyasındaki bir tablonun kayıtlarının ilk satırında olmayan bir koluna sonraki satırlarda bir değer verirseniz, onları null yapıyor. Yani;

<dataset> <item id='1' /> <item id='2' name='first name' /> </dataset>

seklinde verirseniz 2.item'in name koluna null koyacaktir.

Doğrusu;

<dataset> <item id='2' name='first name' /> <item id='1' /> </dataset>

olmalı.

Olmaması gereken bir hata. Hiç olmamış hiç.

Kabul Testleri

Yakinda...