Frobozz

Bir süredir, elimdeki bazı C tabanlı yazılım projelerinde kullanabileceğim ve öğrencilere de önerebileceğim basit bir Birim Test kitaplığı arıyordum. Birim Test konusunu (ve daha genel düzeyde XP’yi) önemsiyorum; disiplinle icra edilen her işi önemsediğim gibi. Nedense bu disiplin ve hackerlık sözcükleri kulağa çok da uyumlu gelen bir terkip oluşturmuyor. Eğer bu uyumsuzluğu gidermek hacker sözcüğünü lugatten silmemi gerektirseydi bu durumu sanıyorum ben de Thomas Dickey gibi gerekçelendirirdim… ve evet Linus Torvalds’ın bu tip konulardaki olumsuz etkisinden haberdarım

Önce hazır Debian paketleri sonra da Google üzerinde yaptığım aramalarda check dışında tatminkâr birşey bulamadım; tâ ki en cutest olanıyla karşılaşıncaya kadar… Doğrusu check‘in de hakkını vermek lâzım, autoconf araçlarıyla uyumlu çalışıyor. Fakat ben biraz daha basit birşeyler peşindeydim. Aslında basitlik sözü beklentimi tam ifade etmiyor. Tekerleği yeniden icat için önemli bir gerekçem olmadığı sürece kullanmaktan kaçınmadığım Glib’le tümleşik bir birim test kitaplığı hemen tercih edebileceğim bir şey olurdu ve bunu yaparken kitaplığın karmaşıklığına değil karmaşıklığı Glib içinde nasıl gizlediğine bakardım. Ama böyle bir kitaplık yok (ben bulamadım en azından). Bu durumda Glib dışına çıkıyorum; bulacağım kitaplığın Glib’in rengi içinde kaybolacak kadar basit olmasını istememin nedeni bu.

Sadece GNOME için değil genel amaçlı bir kitaplık olmak iddiasındaki Glib’de eksikliğini hissettiğim birkaç şeyden biri bu birim test, bir diğeri de “komut satırı ayrıştırıcısı”. GNOME uygulamaları yaygın şekilde popt‘u kullanıyor. Eminim ki bana malum olmayan çeşitli gerekçeleri vardır, fakat neden argp değil? Madem Glib dışında bir çözüm aranacak ve komut satırı bir GUI programı için çok da kritik bir alan değil, bağımlılıkları azaltmak adına argp daha uygun olmaz mıydı? Komut satırı ayrıştırıcısının Glib içinde olmaması benim de zor yoldan öğrendiğim bir yerelleştirme kusuruna yol açıyor. Glib üzerinden g_print ailesi ile görüntülenen yerelleştirilmiş iletilerin doğru şekilde görüntülenmesi için bind_textdomain_codeset(PACKAGE, "UTF-8") gibi reçetelendirilmiş bir çağrı gerekiyor. Sorun şu ki, bu çağrıyı argp‘nin faaliyetlerinden önce yaparsanız komut satırı iletileri Türkçe olarak doğru basılmıyor. Eğer komut satırı ayrıştırıcısı Glib’e tümleşik, yani ileti trafiği için aynı alt yapıyı kullanıyor olsaydı böyle bir sorun da olmayacaktı. popt‘un bu meseleyi erkanına uygun şekilde çözdüğünü de sanmıyorum, fakat aşağı yukarı her GNOME uygulamasında gördüğüm şu libpopt bağımlılığından dolayı hazzetmediğim bu kitaplığı da denemek istemiyorum.

Birim test meselesi… CuTest basit iki dosyadan oluşuyor: CuTest.c ve CuTest.h. CuTest’i kullanan bir gerçek hayat örneği aradım ve izini APR‘de buldum, üstelik tam da benim arzuladığım bazı zenginleştirmelerle. Apache geliştiricileri de basitliğinden dolayı CuTest’i kullanmış. Glib’e alternatif olarak öne sürülebilecek genel amaçlı bir C kitaplığı önermem gerekseydi bu basitçe APR olurdu. Bellek havuzu ve kanallama (threading) özellikleri harika. Apache grubunun yazılım misyonuna da uyuyor, yani taşınabilirliği üst seviyede. Pratik sonuçları itibarıyla bir karşılaştırma yapmam mümkün değil, ama taşınabilirliği Glib’den daha iyi olmalı. APR, Glib bağlamında önemli pratik sonuçlara yol açacak bir farklılık var mamafih. APR, özgür fakat GPL uyumlu olmayan Apache lisansıyla geliyor. Yani projenizde GPL bir bileşen varsa APR’den mahrum kalacaksınız; ufak tefek kod parçaları için benim de sığındığım fair use hali veya kişisel kullanım dışında tabii.

CuTest‘i APR’deki değiştirilmiş haliyle alarak autoconfiscate etmeye çalıştım. Amacım make check ile icra edilen check hedefini gerçeklemekti. Bu tip muhayyer makamlarda kullandığım bir isimlendirmeyle frobozz dizininde başlayan denemeler olumlu sonuçlar verince bu test sürecini daha da otomatize etmek için birkaç betik yazarak tests/Makefile.am‘e ekledim. Fakat automake‘in keder verici kısıtlarından dolayı normalde sıradan bir Makefile’da çalışan birçok numara automake‘de çalışmıyor (ör. *_SOURCES değişkenlerinde dosyaları açık halde vermek gerekiyor, joker karakterler sapıtıyor vb.). Kod üreten betikleri oldum olası sevmemişimdir. Doğru çözüm CuTest’de yani kitaplık düzeyinde değişiklikler yapmaktı ki şu anda kaçındığım bir şey bu. Bu yüzden autoconfiscate sürecini basit tuttum. Böylesi anlaşılırlık adına daha iyi oldu.

Çalışmaların bir noktasında bu işin bir tür şablona dönüştüğünü görerek Glib, debug, profile ve gettext desteği gibi fazladan bir kaç özellik daha ekleyerek frobozz’u genelleştirdim ve son aşamada umumun menfaatini düşünerek frobozz’da şahsıma ait kalıntıları da bul/değiştir yaparak özelleştiren bir frob betiğiyle meseleyi nihayetlendirdim Aslında kalıntılar tamamen kalkmadı; frobozz hâlâ var, bu şablonu bir tar paketi halinde indirebilirsiniz. Bunu yaparken frob betiğini de (son haliyle) depodan almayı unutmayın. Çalışma prensibini ayrıntılı olarak anlatmaya eriniyorum. Kaynak koddaki her foo.c dosyasına bir test suiti muamelesi gösterek buna ait bir tests/test-foo.c dosyası oluşturuyor ve birim test rutinlerini yazıyorum. Test rutinlerini ana kaynak koddan ayırarak kendi başına bir tests dizinine koymak autoconfiscation‘ın bir gereği ve ortalığın düzenli görünmesine de yarıyor. Tabii bunu sağlamak için bir dizi derleme numarası gerekiyordu. Şu erken safhada çok kusuru olduğuna eminim. Denemek isteyeceklere iyi froblamalar!