Autotools projelerinizde u\u00e7tan uca (end-to-end) testleri nas\u0131l entegre edece\u011finizi, yazaca\u011f\u0131n\u0131z\u0131 ve y\u00f6netece\u011finizi ad\u0131m ad\u0131m \u00f6\u011frenin. Sa\u011flam yaz\u0131l\u0131mlar geli\u015ftirin ve yaz\u0131l\u0131m kalitenizi art\u0131r\u0131n.<\/p>\n
Modern yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde, bir uygulaman\u0131n t\u00fcm par\u00e7alar\u0131n\u0131n sorunsuz bir \u015fekilde bir araya gelerek \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olmak kritik bir \u00f6neme sahiptir. Birim testleri tek tek bile\u015fenlerin do\u011frulu\u011funu sa\u011flarken, entegrasyon testleri birka\u00e7 mod\u00fcl\u00fcn birlikte \u00e7al\u0131\u015fmas\u0131n\u0131 kontrol eder. Ancak ya t\u00fcm sistemin, yani veritaban\u0131, a\u011f servisleri, kullan\u0131c\u0131 aray\u00fcz\u00fc ve i\u015f mant\u0131\u011f\u0131n\u0131n bir b\u00fct\u00fcn olarak beklendi\u011fi gibi davrand\u0131\u011f\u0131n\u0131 do\u011frulamak istiyorsak? \u0130\u015fte tam bu noktada, u\u00e7tan uca (End-to-End – E2E) testler devreye giriyor. E2E testler, bir kullan\u0131c\u0131n\u0131n ger\u00e7ek d\u00fcnyadaki etkile\u015fimlerini sim\u00fcle ederek, uygulaman\u0131z\u0131n ba\u015ftan sona do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 garanti alt\u0131na al\u0131r. Bu, geli\u015ftiricilere ve payda\u015flara b\u00fcy\u00fck bir g\u00fcven verir, \u00f6zellikle karma\u015f\u0131k sistemlerde hatalar\u0131 erken a\u015famada yakalamak i\u00e7in vazge\u00e7ilmezdir. Peki, a\u00e7\u0131k kaynak d\u00fcnyas\u0131n\u0131n k\u00f6kl\u00fc ve g\u00fc\u00e7l\u00fc yap\u0131land\u0131rma arac\u0131 Autotools ile bu t\u00fcr testleri nas\u0131l entegre edebiliriz?<\/p>\n
Autotools (Autoconf, Automake, Libtool \u00fc\u00e7l\u00fcs\u00fc), genellikle C ve C++ projelerinde, farkl\u0131 sistemlerde derleme ve kurulum s\u00fcre\u00e7lerini otomatikle\u015ftirmek i\u00e7in kullan\u0131l\u0131r. Bir\u00e7ok b\u00fcy\u00fck a\u00e7\u0131k kaynak projesi, GNU ara\u00e7lar\u0131 ve Linux \u00e7ekirde\u011fi gibi \u00f6nemli yaz\u0131l\u0131mlar Autotools altyap\u0131s\u0131n\u0131 kullan\u0131r. Ancak, Autotools’un test otomasyonu yetenekleri \u00e7o\u011fu zaman g\u00f6z ard\u0131 edilir veya karma\u015f\u0131k bulunur. Oysa Autotools, Yaz\u0131l\u0131m geli\u015ftirmede kalitenin art\u0131r\u0131lmas\u0131, s\u00fcrekli entegrasyon (CI) ve s\u00fcrekli da\u011f\u0131t\u0131m (CD) s\u00fcre\u00e7lerinin temelini olu\u015fturur. E2E testler, bu otomasyon zincirinin \u00f6nemli bir halkas\u0131d\u0131r. Autotools’un sa\u011flaml\u0131\u011f\u0131 ile E2E testlerin kapsaml\u0131l\u0131\u011f\u0131n\u0131 birle\u015ftirerek, yaz\u0131l\u0131m\u0131n\u0131z\u0131n sadece derlenebilir de\u011fil, ayn\u0131 zamanda beklenen \u015fekilde \u00e7al\u0131\u015f\u0131r durumda oldu\u011fundan emin olabilirsiniz. \u015eimdi, bu heyecan verici konunun temel kavramlar\u0131na daha yak\u0131ndan bakal\u0131m.<\/p>\n U\u00e7tan uca testlere ve Autotools’a derinlemesine dalmadan \u00f6nce, bu iki \u00f6nemli kavram\u0131 netle\u015ftirmekte fayda var. Bu sayede, konuya yabanc\u0131 olan okuyucular bile sa\u011flam bir temel \u00fczerine in\u015fa edebilirler.<\/p>\n U\u00e7tan uca testler, bir yaz\u0131l\u0131m uygulamas\u0131n\u0131n t\u00fcm ak\u0131\u015f\u0131n\u0131 ba\u015ftan sona test etme s\u00fcrecidir. Bu testler, uygulaman\u0131n farkl\u0131 katmanlar\u0131n\u0131n (veritaban\u0131, a\u011f, UI, API’ler vb.) birlikte d\u00fczg\u00fcn \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131, yani bir kullan\u0131c\u0131n\u0131n ger\u00e7ek senaryoda kar\u015f\u0131la\u015faca\u011f\u0131 t\u00fcm ad\u0131mlar\u0131 sim\u00fcle ederek do\u011frular. Birim testleri fonksiyonlar\u0131n veya s\u0131n\u0131flar\u0131n izole edilmi\u015f davran\u0131\u015flar\u0131n\u0131 kontrol ederken, entegrasyon testleri birka\u00e7 mod\u00fcl aras\u0131ndaki etkile\u015fimi incelerken, E2E testleri t\u00fcm sistemin bir b\u00fct\u00fcn olarak beklenen i\u015flevselli\u011fi sunup sunmad\u0131\u011f\u0131n\u0131 kontrol eder. \u00d6rne\u011fin, bir CLI uygulamas\u0131nda, bir E2E testi uygulaman\u0131n belirli komutlarla \u00e7a\u011fr\u0131lmas\u0131n\u0131, \u00e7\u0131kt\u0131s\u0131n\u0131n do\u011fru olmas\u0131n\u0131, dosya sistemi \u00fczerinde beklenen etkileri yapmas\u0131n\u0131 ve hatta harici bir servise do\u011fru bir istek g\u00f6nderip almas\u0131n\u0131 do\u011frulayabilir.<\/p>\n Autotools, GNU Projesi’nin bir par\u00e7as\u0131 olarak geli\u015ftirilen ve \u00f6zellikle Unix benzeri sistemlerde yaz\u0131l\u0131m derleme ve kurulumunu kolayla\u015ft\u0131rmak i\u00e7in tasarlanm\u0131\u015f bir ara\u00e7 setidir. Temelde \u00fc\u00e7 ana bile\u015fenden olu\u015fur:<\/p>\n Autotools projelerinde testler genellikle Bu temel kavramlarla donanm\u0131\u015f olarak, art\u0131k Autotools projenizde test altyap\u0131s\u0131n\u0131 ad\u0131m ad\u0131m nas\u0131l kuraca\u011f\u0131m\u0131za ge\u00e7ebiliriz. Bu s\u00fcre\u00e7, projenizin mevcut yap\u0131s\u0131na ba\u011fl\u0131 olarak k\u00fc\u00e7\u00fck de\u011fi\u015fiklikler gerektirebilir ancak genel ad\u0131mlar olduk\u00e7a standartt\u0131r.<\/p>\n Bir Autotools projesine u\u00e7tan uca testleri entegre etmenin ilk ad\u0131m\u0131, testlerin \u00e7al\u0131\u015ft\u0131r\u0131laca\u011f\u0131 bir altyap\u0131 olu\u015fturmakt\u0131r. Bu genellikle projenizin \u0130lk olarak, projenizin ana dizininde testlerinizi bar\u0131nd\u0131racak bir dizin olu\u015fturmal\u0131s\u0131n\u0131z. Genellikle bu dizine <\/code><\/p>\n <\/code><\/p>\n Bu de\u011fi\u015fiklik, Projenizin ana <\/code><\/p>\n \u015eimdi s\u0131ra, as\u0131l testleri bar\u0131nd\u0131racak olan <\/code><\/p>\n Bu ad\u0131mlar\u0131 tamamlad\u0131\u011f\u0131n\u0131zda, Autotools projenizin test altyap\u0131s\u0131 haz\u0131r demektir. Projenizi yeniden yap\u0131land\u0131r\u0131p derledikten sonra ( Art\u0131k Autotools projemizde test altyap\u0131s\u0131n\u0131 kurdu\u011fumuza g\u00f6re, s\u0131ra geldi ger\u00e7ek test senaryolar\u0131n\u0131 yazmaya. U\u00e7tan uca testler genellikle kabuk betikleri (shell scripts) veya Python, Perl gibi betik dilleri kullan\u0131larak yaz\u0131l\u0131r. Bu diller, sistem komutlar\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rma, \u00e7\u0131kt\u0131lar\u0131 yakalama ve dosya sistemiyle etkile\u015fim kurma konusunda olduk\u00e7a esneklik sunar.<\/p>\n Basit bir C program\u0131 yazd\u0131\u011f\u0131m\u0131z\u0131 varsayal\u0131m. Bu program, kendisine verilen iki say\u0131y\u0131 toplay\u0131p sonucu d\u00f6nd\u00fcr\u00fcyor veya ge\u00e7ersiz arg\u00fcmanlarda hata mesaj\u0131 veriyor:<\/p>\n <\/code><\/p>\n Bu program\u0131 derleyebilmek i\u00e7in ana <\/code><\/p>\n Bu toplama program\u0131 i\u00e7in ba\u015far\u0131l\u0131 bir senaryoyu test eden bir kabuk beti\u011fi yazal\u0131m. Beti\u011fimizin amac\u0131, program\u0131 do\u011fru arg\u00fcmanlarla \u00e7al\u0131\u015ft\u0131rmak ve \u00e7\u0131kt\u0131s\u0131n\u0131n beklendi\u011fi gibi olup olmad\u0131\u011f\u0131n\u0131 kontrol etmektir.<\/p>\n <\/code><\/p>\n \u015eimdi de ge\u00e7ersiz arg\u00fcmanlarla bir hata senaryosunu test eden bir betik yazal\u0131m. Burada program\u0131n hata kodu d\u00f6nd\u00fcrmesi ve standart hata \u00e7\u0131kt\u0131s\u0131na do\u011fru mesaj\u0131 yazmas\u0131 beklenir.<\/p>\n <\/code><\/p>\n Bu betiklerde, <\/strong><\/p>\n Bu yeni test betiklerini <\/code><\/p>\n Bu ad\u0131mlarla, Autotools projenizde u\u00e7tan uca test senaryolar\u0131n\u0131z\u0131 yazabilir ve \u015eimdiye kadar basit bir toplama uygulamas\u0131 \u00fczerinde \u00e7al\u0131\u015ft\u0131k. Ancak ger\u00e7ek d\u00fcnya uygulamalar\u0131 genellikle daha karma\u015f\u0131kt\u0131r; dosya sistemiyle etkile\u015fime girer, harici ba\u011f\u0131ml\u0131l\u0131klar\u0131 olabilir veya daha karma\u015f\u0131k komut sat\u0131r\u0131 aray\u00fczleri sunar. Bu b\u00f6l\u00fcmde, daha karma\u015f\u0131k bir CLI arac\u0131 \u00f6rne\u011fi \u00fczerinden u\u00e7tan uca testlerin nas\u0131l yaz\u0131laca\u011f\u0131n\u0131 ele alaca\u011f\u0131z.<\/p>\n Hayal edin ki, bir CLI uygulamam\u0131z var: Bu t\u00fcr bir uygulama i\u00e7in \u00e7e\u015fitli E2E test senaryolar\u0131 d\u00fc\u015f\u00fcnebiliriz:<\/p>\n Bu test, uygulaman\u0131n temel i\u015flevselli\u011fini do\u011frular. Bir ge\u00e7ici JSON dosyas\u0131 olu\u015fturur, uygulamay\u0131 bu dosya ve bir anahtar ile \u00e7al\u0131\u015ft\u0131r\u0131r ve \u00e7\u0131kt\u0131y\u0131 kontrol eder.<\/p>\n <\/code><\/p>\n Bu test, uygulaman\u0131n hata y\u00f6netimi yeteneklerini do\u011frular. Bozuk bir JSON dosyas\u0131 ile \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda uygun bir hata mesaj\u0131 ve \u00e7\u0131k\u0131\u015f kodu beklenecektir.<\/p>\n <\/code><\/p>\n Daha karma\u015f\u0131k komut sat\u0131r\u0131 se\u00e7eneklerini ve \u00e7\u0131kt\u0131 formatlamay\u0131 test edebiliriz.<\/p>\n <\/code><\/p>\n U\u00e7tan uca testler bazen beklendi\u011fi gibi \u00e7al\u0131\u015fmayabilir. Bu durumda hata ay\u0131klama \u00f6nemlidir:<\/p>\n Bu b\u00f6l\u00fcm, Autotools ile karma\u015f\u0131k bir uygulaman\u0131n u\u00e7tan uca testlerinin nas\u0131l yaz\u0131labilece\u011fine dair pratik bir bak\u0131\u015f a\u00e7\u0131s\u0131 sundu. Betik dillerinin esnekli\u011fini kullanarak, uygulaman\u0131z\u0131n t\u00fcm katmanlar\u0131n\u0131 kapsayan sa\u011flam testler olu\u015fturabilirsiniz. Bir sonraki b\u00f6l\u00fcmde, daha deneyimli kullan\u0131c\u0131lar i\u00e7in paralel test \u00e7al\u0131\u015ft\u0131rma ve raporlama gibi ileri d\u00fczey konulara odaklanaca\u011f\u0131z.<\/p>\n JSON parser testleri i\u00e7in <\/code><\/p>\n Bu kurulumla, B\u00fcy\u00fck projelerde \u00e7ok say\u0131da u\u00e7tan uca test oldu\u011funda, test s\u00fcresi \u00f6nemli bir darbo\u011faz haline gelebilir. Autotools, bu sorunu \u00e7\u00f6zmek i\u00e7in baz\u0131 mekanizmalar sunar. Ayr\u0131ca, test sonu\u00e7lar\u0131n\u0131 sadece ge\u00e7ip ge\u00e7medi\u011fini g\u00f6rmekle kalmay\u0131p, daha anlaml\u0131 raporlar halinde sunmak da \u00f6nemlidir. Bu b\u00f6l\u00fcmde, bu ileri d\u00fczey konular\u0131 inceleyece\u011fiz.<\/p>\n Autotools tabanl\u0131 projelerde testleri paralel olarak \u00e7al\u0131\u015ft\u0131rmak olduk\u00e7a basittir, \u00e7\u00fcnk\u00fc <\/code><\/p>\n Bu komut, Autotools'un varsay\u0131lan Varsay\u0131lan olarak, bir test beti\u011fi 0 \u00e7\u0131k\u0131\u015f kodu d\u00f6nd\u00fcr\u00fcrse ba\u015far\u0131l\u0131 say\u0131l\u0131r, 0'dan farkl\u0131 bir kod d\u00f6nd\u00fcr\u00fcrse ba\u015far\u0131s\u0131z say\u0131l\u0131r. Autotools'un kendisi do\u011frudan JUnit XML veya Test Anything Protocol (TAP) gibi modern test raporlama formatlar\u0131n\u0131 desteklemez. Ancak, test betikleriniz bu formatlarda \u00e7\u0131kt\u0131 \u00fcretecek \u015fekilde yaz\u0131labilir ve bu \u00e7\u0131kt\u0131lar daha sonra CI\/CD ara\u00e7lar\u0131 taraf\u0131ndan i\u015flenebilir.<\/p>\n \u00d6rne\u011fin, bir Python beti\u011fi kullanarak JUnit XML \u00e7\u0131kt\u0131s\u0131 \u00fcretebilirsiniz. Kabuk beti\u011finiz bu Python beti\u011fini \u00e7a\u011f\u0131rabilir.<\/p>\n <\/code><\/p>\n Daha sonra test beti\u011finizin sonunda, bu Python beti\u011fini \u00e7a\u011f\u0131rarak test sonucunu bir XML dosyas\u0131na yazabilirsiniz.<\/p>\n Autotools tabanl\u0131 projeler i\u00e7in CI\/CD entegrasyonu olduk\u00e7a basittir. Temel ad\u0131mlar \u015funlard\u0131r:<\/p>\n <\/code><\/p>\n Bu \u015fekilde, Autotools projelerinizin testleri otomatik olarak \u00e7al\u0131\u015ft\u0131r\u0131labilir ve sonu\u00e7lar CI\/CD pipeline'\u0131n\u0131z\u0131n bir par\u00e7as\u0131 olarak takip edilebilir. Bu, yaz\u0131l\u0131m kalitesini s\u00fcrekli olarak izlemenizi ve olas\u0131 regresyonlar\u0131 h\u0131zla tespit etmenizi sa\u011flar.<\/p>\n Autotools ile u\u00e7tan uca testler geli\u015ftirirken baz\u0131 yayg\u0131n sorunlarla kar\u015f\u0131la\u015fmak olas\u0131d\u0131r. Bu b\u00f6l\u00fcmde, bu sorunlar\u0131 ve pratik \u00e7\u00f6z\u00fcm yollar\u0131n\u0131 ele alaca\u011f\u0131z.<\/p>\n Belirti:<\/b> Olas\u0131 Nedenler ve \u00c7\u00f6z\u00fcmler:<\/b><\/p>\n Belirti:<\/b> Bir test ba\u015far\u0131s\u0131z oluyor ancak konsolda sadece \"X test failed\" gibi genel bir mesaj g\u00f6r\u00fcn\u00fcyor. Neden ba\u015far\u0131s\u0131z oldu\u011funu anlamak zorla\u015f\u0131yor.<\/p>\n Olas\u0131 Nedenler ve \u00c7\u00f6z\u00fcmler:<\/b><\/p>\nmake check<\/code> komutu arac\u0131l\u0131\u011f\u0131yla projelerimize sa\u011flam bir test s\u00fciti entegre etmemiz i\u00e7in olduk\u00e7a esnek bir yap\u0131 sunar. Bu makale boyunca, Autotools tabanl\u0131 projelerinize nas\u0131l u\u00e7tan uca testler yazaca\u011f\u0131n\u0131z\u0131, bu testleri nas\u0131l \u00e7al\u0131\u015ft\u0131raca\u011f\u0131n\u0131z\u0131 ve hatta ileri d\u00fczeyde nas\u0131l y\u00f6netece\u011finizi ad\u0131m ad\u0131m inceleyece\u011fiz. Amac\u0131m\u0131z, geli\u015ftirme s\u00fcre\u00e7lerinizi daha verimli, yaz\u0131l\u0131mlar\u0131n\u0131z\u0131 ise daha g\u00fcvenilir hale getirmektir. Bu sayede, hem kendinizin hem de kullan\u0131c\u0131lar\u0131n\u0131z\u0131n yaz\u0131l\u0131m\u0131n\u0131za olan g\u00fcvenini art\u0131rabilirsiniz.<\/p>\nTemel Kavramlar: U\u00e7tan Uca Testler ve Autotools Ekosistemi Nedir?<\/h2>\n
U\u00e7tan Uca (End-to-End) Testler Nelerdir?<\/h3>\n
\n
Autotools Ekosistemi: K\u0131sa Bir Bak\u0131\u015f<\/h3>\n
\n
configure.ac<\/code> veya configure.in<\/code> dosyas\u0131ndan, kullan\u0131c\u0131 sisteminde \u00e7al\u0131\u015facak configure<\/code> beti\u011fini \u00fcretir. Bu betik, derleme ortam\u0131n\u0131 kontrol eder (derleyici, k\u00fct\u00fcphaneler, ba\u015fl\u0131k dosyalar\u0131 vb. var m\u0131?) ve projenin o ortama g\u00f6re yap\u0131land\u0131r\u0131lmas\u0131n\u0131 sa\u011flar.<\/li>\nMakefile.am<\/code> dosyas\u0131ndan, configure<\/code> beti\u011fi taraf\u0131ndan kullan\u0131lacak Makefile.in<\/code> dosyalar\u0131n\u0131 \u00fcretir. Makefile.am<\/code>, projenin derlenmesi, kurulmas\u0131 ve test edilmesi i\u00e7in gerekli kurallar\u0131 tan\u0131mlar.<\/li>\nmake check<\/code> komutuyla \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r. Bu komut, Makefile.am<\/code> i\u00e7inde tan\u0131mlanan check<\/code> hedefini tetikler ve bu hedefe ba\u011fl\u0131 olan t\u00fcm testleri s\u0131ras\u0131yla \u00e7al\u0131\u015ft\u0131r\u0131r. Test sonu\u00e7lar\u0131 genellikle standart \u00e7\u0131kt\u0131ya yaz\u0131l\u0131r ve test beti\u011finin \u00e7\u0131k\u0131\u015f kodu (0 ba\u015far\u0131, di\u011ferleri hata) sonucun ba\u015far\u0131l\u0131 olup olmad\u0131\u011f\u0131n\u0131 belirler. Bu mekanizma, u\u00e7tan uca testlerimizi entegre etmek i\u00e7in m\u00fckemmel bir zemin haz\u0131rlar.<\/p>\nAutotools Projelerinde Test Altyap\u0131s\u0131n\u0131 Kurmak: Nas\u0131l Ba\u015flan\u0131r?<\/h2>\n
configure.ac<\/code> ve Makefile.am<\/code> dosyalar\u0131nda baz\u0131 de\u011fi\u015fiklikler yapmay\u0131 ve testlerinizi i\u00e7erecek yeni bir dizin olu\u015fturmay\u0131 gerektirir.<\/p>\n1. Test Dizinini Olu\u015fturma<\/h3>\n
tests\/<\/code> ad\u0131 verilir. \u0130\u00e7erisinde test betiklerinizi ve bu testlere \u00f6zg\u00fc Makefile.am<\/code> dosyas\u0131n\u0131 bulunduracakt\u0131r.<\/p>\n\nmkdir tests\ntouch tests\/Makefile.am\n<\/pre>\n2.
configure.ac<\/code> Dosyas\u0131n\u0131 G\u00fcncelleme<\/h3>\nconfigure.ac<\/code> dosyas\u0131, Autoconf'un projenizi yap\u0131land\u0131rmak i\u00e7in kulland\u0131\u011f\u0131 temel dosyad\u0131r. Test dizininizin de yap\u0131land\u0131rma s\u00fcrecine dahil edildi\u011finden emin olmal\u0131y\u0131z. Bunun i\u00e7in, AC_OUTPUT<\/code> makrosuna tests\/Makefile<\/code>'\u0131 eklemelisiniz. Ayr\u0131ca, testler i\u00e7in baz\u0131 temel programlar\u0131n (\u00f6rne\u011fin, grep<\/code>, sed<\/code>, diff<\/code> gibi yayg\u0131n Unix ara\u00e7lar\u0131) varl\u0131\u011f\u0131n\u0131 kontrol etmek isteyebilirsiniz.<\/p>\n\n# configure.ac dosyas\u0131ndan bir kesit\nAC_INIT([myproject], [1.0], [bug-report@example.com])\nAM_INIT_AUTOMAKE([-Wall gnu dist-bzip2])\nAC_PROG_CC\nAC_PROG_INSTALL\nAM_SILENT_RULES([yes]) # Daha sessiz derleme \u00e7\u0131kt\u0131s\u0131 i\u00e7in\n\n# ... di\u011fer kontroller ...\n\n# Test dizinini yap\u0131land\u0131rmaya dahil et\nAC_CONFIG_FILES([\n Makefile\n tests\/Makefile\n])\nAC_OUTPUT\n<\/pre>\nconfigure<\/code> beti\u011fi \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda tests\/Makefile.in<\/code> dosyas\u0131ndan tests\/Makefile<\/code> dosyas\u0131n\u0131n olu\u015fturulmas\u0131n\u0131 sa\u011flar. B\u00f6ylece test dizininiz de derleme ve test s\u00fcrecine dahil edilmi\u015f olur.<\/p>\n3. Ana
Makefile.am<\/code> Dosyas\u0131n\u0131 G\u00fcncelleme<\/h3>\nMakefile.am<\/code> dosyas\u0131nda, tests\/<\/code> dizinini alt dizin olarak tan\u0131mlaman\u0131z gerekir. Bu, make<\/code> komutunun ana dizinden tests\/<\/code> dizinindeki Makefile<\/code>'\u0131 da i\u015fleyebilmesini sa\u011flar.<\/p>\n\n# Makefile.am dosyas\u0131ndan bir kesit\nAUTOMAKE_OPTIONS = foreign\n\n# Ana programlar\u0131n\u0131z\u0131n veya k\u00fct\u00fcphanelerinizin tan\u0131mlar\u0131\nbin_PROGRAMS = my_app\nmy_app_SOURCES = src\/main.c src\/utils.c\n\n# ... di\u011fer tan\u0131mlar ...\n\n# Test dizinini alt dizin olarak ekle\nSUBDIRS = . tests\n<\/pre>\nSUBDIRS = . tests<\/code> sat\u0131r\u0131, make<\/code> komutunun \u00f6nce ge\u00e7erli dizindeki Makefile<\/code>'\u0131, ard\u0131ndan tests\/<\/code> dizinindeki Makefile<\/code>'\u0131 i\u015fleyece\u011fini belirtir. B\u00f6ylece, make check<\/code> komutu \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda, Autotools tests\/<\/code> dizinindeki testleri de otomatik olarak tetikleyebilir.<\/p>\n4.
tests\/Makefile.am<\/code> Dosyas\u0131n\u0131 Tan\u0131mlama<\/h3>\ntests\/Makefile.am<\/code> dosyas\u0131n\u0131 yap\u0131land\u0131rmaya geldi. Bu dosya, \u00e7al\u0131\u015ft\u0131r\u0131lacak test betiklerini veya programlar\u0131n\u0131 tan\u0131mlar. En basit haliyle, test betiklerini check_SCRIPTS<\/code> de\u011fi\u015fkeniyle tan\u0131mlayabilirsiniz.<\/p>\n\n# tests\/Makefile.am\n# Test betiklerinin \u00e7al\u0131\u015ft\u0131r\u0131laca\u011f\u0131 dizin\nTESTS_ENVIRONMENT = srcdir=$(srcdir) builddir=$(builddir)\nTESTS = test_hello.sh test_feature_x.sh\n\n# Test betiklerini buraya ekleyin\ncheck_SCRIPTS = $(TESTS)\n\n# Testlerin \u00e7al\u0131\u015ft\u0131r\u0131labilmesi i\u00e7in gerekli programlar\u0131n derlenmesi (iste\u011fe ba\u011fl\u0131)\n# check_PROGRAMS = test_runner\n# test_runner_SOURCES = test_runner.c\n<\/pre>\nTESTS_ENVIRONMENT<\/code> de\u011fi\u015fkeni, test betiklerinin \u00e7al\u0131\u015ft\u0131\u011f\u0131 ortam i\u00e7in ek de\u011fi\u015fkenler tan\u0131mlaman\u0131za olanak tan\u0131r. srcdir<\/code> ve builddir<\/code> genellikle test betiklerinin kaynak ve derleme dizinlerine eri\u015fmesi i\u00e7in kullan\u0131\u015fl\u0131d\u0131r. TESTS<\/code> de\u011fi\u015fkeni ise \u00e7al\u0131\u015ft\u0131r\u0131lacak test betiklerinin bir listesidir. check_SCRIPTS<\/code> de\u011fi\u015fkeni de bu listeyi kullanarak Autotools'a hangi betiklerin make check<\/code> ile \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131 gerekti\u011fini bildirir.<\/p>\nautoreconf -fis && .\/configure && make<\/code>), make check<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda Autotools, tests\/<\/code> dizinindeki tan\u0131mlanm\u0131\u015f test betiklerinizi \u00e7al\u0131\u015ft\u0131rmaya ba\u015flayacakt\u0131r. \u015eimdi, bu betikleri nas\u0131l yazaca\u011f\u0131m\u0131za odaklanabiliriz.<\/p>\nU\u00e7tan Uca Test Senaryolar\u0131 Yazma: Uygulamal\u0131 Yakla\u015f\u0131m<\/h2>\n
Basit Bir CLI Uygulamas\u0131 \u00dczerinde \u00d6rnek<\/h3>\n
\n\/\/ src\/main.c\n#include Makefile.am<\/code> dosyas\u0131nda \u015fu tan\u0131mlar olmal\u0131:<\/p>\n\n# Makefile.am\nbin_PROGRAMS = my_adder\nmy_adder_SOURCES = src\/main.c\n<\/pre>\nTest Beti\u011fi Yazma:
test_adder_valid.sh<\/code><\/h3>\n\n#!\/bin\/bash\n# tests\/test_adder_valid.sh\n\n# Testin \u00e7al\u0131\u015ft\u0131r\u0131laca\u011f\u0131 ge\u00e7ici dizin olu\u015ftur\nTEST_DIR=$(mktemp -d)\nif [ ! -d \"$TEST_DIR\" ]; then\n echo \"HATA: Ge\u00e7ici dizin olu\u015fturulamad\u0131.\"\n exit 1\nfi\ncd \"$TEST_DIR\" || exit 1\n\n# Derlenmi\u015f my_adder program\u0131n\u0131n yolunu bul\n# builddir, configure taraf\u0131ndan tan\u0131mlan\u0131r ve tests\/Makefile.am'e iletilir\nMY_ADDER_PROG=\"${builddir}\/my_adder\"\n\n# Program\u0131n varl\u0131\u011f\u0131n\u0131 kontrol et\nif [ ! -f \"$MY_ADDER_PROG\" ]; then\n echo \"HATA: my_adder program\u0131 bulunamad\u0131: $MY_ADDER_PROG\"\n rm -rf \"$TEST_DIR\"\n exit 1\nfi\n\necho \"--- Test Ba\u015fl\u0131yor: Ge\u00e7erli Arg\u00fcmanlarla Toplama ---\"\n\n# Program\u0131 \u00e7al\u0131\u015ft\u0131r ve \u00e7\u0131kt\u0131s\u0131n\u0131 yakala\nOUTPUT=$(\"$MY_ADDER_PROG\" 5 3)\nEXIT_CODE=$?\n\n# \u00c7\u0131k\u0131\u015f kodunu kontrol et\nif [ \"$EXIT_CODE\" -ne 0 ]; then\n echo \"HATA: Program beklenenden farkl\u0131 bir \u00e7\u0131k\u0131\u015f kodu d\u00f6nd\u00fcrd\u00fc: $EXIT_CODE\"\n echo \"\u00c7\u0131kt\u0131: $OUTPUT\"\n rm -rf \"$TEST_DIR\"\n exit 1\nfi\n\n# \u00c7\u0131kt\u0131y\u0131 kontrol et\nEXPECTED_OUTPUT=\"Toplam: 8\"\nif [ \"$OUTPUT\" != \"$EXPECTED_OUTPUT\" ]; then\n echo \"HATA: Program \u00e7\u0131kt\u0131s\u0131 beklenenden farkl\u0131.\"\n echo \"Beklenen: '$EXPECTED_OUTPUT'\"\n echo \"Al\u0131nan: '$OUTPUT'\"\n rm -rf \"$TEST_DIR\"\n exit 1\nfi\n\necho \"--- Test BA\u015eARILI ---\"\n# Ge\u00e7ici dizini temizle\nrm -rf \"$TEST_DIR\"\nexit 0\n<\/pre>\nTest Beti\u011fi Yazma:
test_adder_invalid.sh<\/code><\/h3>\n\n#!\/bin\/bash\n# tests\/test_adder_invalid.sh\n\nTEST_DIR=$(mktemp -d)\nif [ ! -d \"$TEST_DIR\" ]; then\n echo \"HATA: Ge\u00e7ici dizin olu\u015fturulamad\u0131.\"\n exit 1\nfi\ncd \"$TEST_DIR\" || exit 1\n\nMY_ADDER_PROG=\"${builddir}\/my_adder\"\n\nif [ ! -f \"$MY_ADDER_PROG\" ]; then\n echo \"HATA: my_adder program\u0131 bulunamad\u0131: $MY_ADDER_PROG\"\n rm -rf \"$TEST_DIR\"\n exit 1\nfi\n\necho \"--- Test Ba\u015fl\u0131yor: Ge\u00e7ersiz Arg\u00fcmanlarla Toplama ---\"\n\n# Program\u0131 ge\u00e7ersiz arg\u00fcmanlarla \u00e7al\u0131\u015ft\u0131r ve standart hata \u00e7\u0131kt\u0131s\u0131n\u0131 yakala\nERROR_OUTPUT=$(\"$MY_ADDER_PROG\" 5 2>&1 >\/dev\/null) # stdout'u yok say, stderr'i yakala\nEXIT_CODE=$?\n\n# \u00c7\u0131k\u0131\u015f kodunu kontrol et (beklenen 1)\nif [ \"$EXIT_CODE\" -ne 1 ]; then\n echo \"HATA: Program beklenenden farkl\u0131 bir \u00e7\u0131k\u0131\u015f kodu d\u00f6nd\u00fcrd\u00fc: $EXIT_CODE\"\n echo \"Hata \u00c7\u0131kt\u0131s\u0131: $ERROR_OUTPUT\"\n rm -rf \"$TEST_DIR\"\n exit 1\nfi\n\n# Hata \u00e7\u0131kt\u0131s\u0131n\u0131 kontrol et\nEXPECTED_ERROR=\"Kullan\u0131m: ${MY_ADDER_PROG*\/} ${MY_ADDER_PROG*\/}<\/code> ifadesi, program\u0131n tam yolundan sadece ad\u0131n\u0131 almak i\u00e7in kullan\u0131l\u0131r, bu da hata mesaj\u0131n\u0131n do\u011fru \u015fekilde e\u015fle\u015fmesini sa\u011flar.<\/p>\ntests\/Makefile.am<\/code> G\u00fcncellemesi<\/h3>\ntests\/Makefile.am<\/code> dosyan\u0131za eklemeyi unutmay\u0131n:<\/p>\n\n# tests\/Makefile.am\nTESTS_ENVIRONMENT = srcdir=$(srcdir) builddir=..\/$(builddir) # builddir'i d\u00fczeltildi\nTESTS = test_adder_valid.sh \\\n test_adder_invalid.sh\n\ncheck_SCRIPTS = $(TESTS)\n\n# Test betiklerinin \u00e7al\u0131\u015ft\u0131r\u0131labilmesi i\u00e7in gerekli olan my_adder'\u0131 burada tan\u0131mla\n# B\u00f6ylece \"make check\" \u00f6ncesinde my_adder derlenir.\nnoinst_PROGRAMS = my_adder\nmy_adder_SOURCES = src\/main.c\nmy_adder_CFLAGS = -I$(srcdir)\/..\/src # Kaynak dosyalara eri\u015fim i\u00e7in (e\u011fer src\/main.c bu dizinde de\u011filse)\n\n# E\u011fer my_adder \u00fcst dizinde derleniyorsa, burada yeniden derlememek i\u00e7in:\n# TESTS_ENVIRONMENT = ...; export PATH=\"$(abs_builddir):$PATH\"\n# my_adder_PROGRAMS yoksa, TEST_DIR'da do\u011frudan builddir\/my_adder kullan\u0131labilir\n<\/pre>\ntests\/Makefile.am<\/code> i\u00e7inde noinst_PROGRAMS<\/code> ile testler i\u00e7in \u00f6zel olarak derlenecek programlar tan\u0131mlayabilirsiniz. Ya da TESTS_ENVIRONMENT<\/code> i\u00e7inde PATH<\/code> de\u011fi\u015fkenini ayarlayarak ana projenin derlenmi\u015f programlar\u0131na eri\u015fim sa\u011flayabilirsiniz. \u0130kinci yakla\u015f\u0131m, ana program\u0131 tekrar derlemeye gerek kalmad\u0131\u011f\u0131 i\u00e7in daha verimli olabilir. builddir=..\/$(builddir)<\/code> d\u00fczeltmesi, test dizininden ana dizine relative path i\u00e7in gereklidir.\n<\/div>\nmake check<\/code> komutuyla \u00e7al\u0131\u015ft\u0131rabilirsiniz. Her test beti\u011fi, program\u0131n\u0131z\u0131n belirli bir y\u00f6n\u00fcn\u00fc veya bir kullan\u0131m senaryosunu do\u011frulamal\u0131d\u0131r. Bir sonraki b\u00f6l\u00fcmde, daha karma\u015f\u0131k, ger\u00e7ek d\u00fcnya senaryolar\u0131nda bu yakla\u015f\u0131m\u0131 nas\u0131l uygulayabilece\u011fimizi ke\u015ffedece\u011fiz.<\/p>\nGer\u00e7ek D\u00fcnya Senaryosu: Karma\u015f\u0131k Bir Uygulaman\u0131n U\u00e7tan Uca Testi<\/h2>\n
Vaka Analizi: Bir Basit JSON \u0130\u015fleyici CLI Arac\u0131<\/h3>\n
json-parser<\/code>. Bu ara\u00e7, JSON dosyalar\u0131n\u0131 okuyabilir, belirli anahtarlara g\u00f6re filtreleme yapabilir ve \u00e7\u0131kt\u0131y\u0131 farkl\u0131 formatlarda (\u00f6rne\u011fin, sadece de\u011ferler) yazd\u0131rabilir. Proje yap\u0131m\u0131z a\u015fa\u011f\u0131daki gibi olsun:<\/p>\n\n
src\/<\/code>: C kaynak kodlar\u0131<\/li>\nconfigure.ac<\/code><\/li>\nMakefile.am<\/code><\/li>\ntests\/<\/code>: Test betikleri burada olacak<\/li>\n<\/ul>\njson-parser<\/code>'\u0131n baz\u0131 \u00f6zellikleri:<\/p>\n\n
json-parser --file input.json --key name<\/code>: input.json<\/code> dosyas\u0131ndan \"name\" anahtar\u0131n\u0131n de\u011ferini d\u00f6nd\u00fcr\u00fcr.<\/li>\njson-parser --file input.json --keys name age<\/code>: Birden fazla anahtar\u0131n de\u011ferlerini d\u00f6nd\u00fcr\u00fcr.<\/li>\nTest Senaryolar\u0131 ve Betikleri<\/h3>\n
Senaryo 1: Ge\u00e7erli JSON Dosyas\u0131ndan Tek Anahtar Okuma<\/h4>\n
\n#!\/bin\/bash\n# tests\/test_json_single_key.sh\n\nTEST_DIR=$(mktemp -d)\ncd \"$TEST_DIR\" || exit 1\n\nJSON_PARSER_PROG=\"${builddir}\/json-parser\"\n\nif [ ! -f \"$JSON_PARSER_PROG\" ]; then\n echo \"HATA: json-parser program\u0131 bulunamad\u0131.\"\n rm -rf \"$TEST_DIR\"\n exit 1\nfi\n\necho \"--- Test Ba\u015fl\u0131yor: Tek Anahtar Okuma ---\"\n\n# Ge\u00e7ici JSON dosyas\u0131 olu\u015ftur\ncat <Senaryo 2: Ge\u00e7ersiz JSON Dosyas\u0131 \u0130\u015fleme<\/h4>\n
\n#!\/bin\/bash\n# tests\/test_json_invalid_input.sh\n\nTEST_DIR=$(mktemp -d)\ncd \"$TEST_DIR\" || exit 1\n\nJSON_PARSER_PROG=\"${builddir}\/json-parser\"\n\nif [ ! -f \"$JSON_PARSER_PROG\" ]; then\n echo \"HATA: json-parser program\u0131 bulunamad\u0131.\"\n rm -rf \"$TEST_DIR\"\n exit 1\nfi\n\necho \"--- Test Ba\u015fl\u0131yor: Ge\u00e7ersiz JSON ---\"\n\n# Ge\u00e7ersiz JSON dosyas\u0131 olu\u015ftur\necho \"{ 'name': 'Bob', }\" > invalid.json\n\n# Program\u0131 \u00e7al\u0131\u015ft\u0131r ve stderr'i yakala\nERROR_OUTPUT=$(\"$JSON_PARSER_PROG\" --file invalid.json --key name 2>&1 >\/dev\/null)\nEXIT_CODE=$?\n\nif [ \"$EXIT_CODE\" -eq 0 ]; then\n echo \"HATA: Program hata kodu d\u00f6nd\u00fcrmedi (beklenen 1).\"\n echo \"\u00c7\u0131kt\u0131: $ERROR_OUTPUT\"\n rm -rf \"$TEST_DIR\"\n exit 1\nfi\n\n# Hata \u00e7\u0131kt\u0131s\u0131n\u0131n belirli bir mesaj i\u00e7erdi\u011fini do\u011frula\nif [[ ! \"$ERROR_OUTPUT\" =~ \"JSON ayr\u0131\u015ft\u0131rma hatas\u0131\" ]]; then\n echo \"HATA: Beklenmeyen hata mesaj\u0131.\"\n echo \"Al\u0131nan: '$ERROR_OUTPUT'\"\n rm -rf \"$TEST_DIR\"\n exit 1\nfi\n\necho \"--- Test BA\u015eARILI ---\"\nrm -rf \"$TEST_DIR\"\nexit 0\n<\/pre>\nSenaryo 3: Birden Fazla Anahtar Okuma ve Formatlama<\/h4>\n
\n#!\/bin\/bash\n# tests\/test_json_multiple_keys.sh\n\nTEST_DIR=$(mktemp -d)\ncd \"$TEST_DIR\" || exit 1\n\nJSON_PARSER_PROG=\"${builddir}\/json-parser\"\n\nif [ ! -f \"$JSON_PARSER_PROG\" ]; then\n echo \"HATA: json-parser program\u0131 bulunamad\u0131.\"\n rm -rf \"$TEST_DIR\"\n exit 1\nfi\n\necho \"--- Test Ba\u015fl\u0131yor: Birden Fazla Anahtar Okuma ---\"\n\ncat <Hata Ay\u0131klama \u0130pu\u00e7lar\u0131<\/h3>\n
\n
make check<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131rken AM_V_GEN=1<\/code> veya V=1<\/code> gibi de\u011fi\u015fkenler kullanarak daha detayl\u0131 \u00e7\u0131kt\u0131 alabilirsiniz. Bu, hangi komutlar\u0131n \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131n\u0131 g\u00f6rmenizi sa\u011flar. \u00d6rne\u011fin: make AM_V_GEN=1 check<\/code>.<\/li>\ntests\/<\/code> dizininden \u00e7al\u0131\u015ft\u0131rarak (\u00f6rne\u011fin .\/tests\/test_json_invalid_input.sh<\/code>) sorunu daha h\u0131zl\u0131 tespit edebilirsiniz. Beti\u011fe set -x<\/code> ekleyerek t\u00fcm komutlar\u0131n \u00e7al\u0131\u015fmadan \u00f6nce yazd\u0131r\u0131lmas\u0131n\u0131 sa\u011flayabilirsiniz.<\/li>\nrm -rf \"$TEST_DIR\"<\/code> komutunu ge\u00e7ici olarak yorum sat\u0131r\u0131 yap\u0131n. B\u00f6ylece ba\u015far\u0131s\u0131z olan testin olu\u015fturdu\u011fu t\u00fcm dosyalar\u0131 inceleyebilirsiniz.<\/li>\n<\/ol>\ntests\/Makefile.am<\/code> G\u00fcncellemesi (JSON Parser i\u00e7in)<\/h3>\ntests\/Makefile.am<\/code> dosyas\u0131 \u015fu \u015fekilde g\u00fcncellenebilir:<\/p>\n\n# tests\/Makefile.am\nTESTS_ENVIRONMENT = srcdir=$(srcdir) builddir=..\/$(builddir)\nTESTS = test_json_single_key.sh \\\n test_json_invalid_input.sh \\\n test_json_multiple_keys.sh\n\ncheck_SCRIPTS = $(TESTS)\n\n# json-parser program\u0131n\u0131 test dizininde derlemek i\u00e7in\n# (e\u011fer ana Makefile.am'de zaten tan\u0131ml\u0131 de\u011filse veya testlerin \u00f6zel bir s\u00fcr\u00fcm\u00fcn\u00fc istiyorsan\u0131z)\nnoinst_PROGRAMS = json-parser\njson_parser_SOURCES = src\/json_parser.c src\/utils.c # \u00d6rnek kaynak dosyalar\njson_parser_LDADD = -ljson # Varsay\u0131msal bir JSON k\u00fct\u00fcphanesi ba\u011f\u0131ml\u0131l\u0131\u011f\u0131\n\n# E\u011fer json-parser ana dizinde derleniyorsa, sadece yolunu belirtmek yeterlidir:\n# TESTS_ENVIRONMENT = PATH=\"$(abs_builddir):$PATH\"\n# noinst_PROGRAMS tan\u0131mlamaya gerek kalmaz.\n<\/pre>\nmake check<\/code> komutu json-parser<\/code>'\u0131 derleyecek (e\u011fer noinst_PROGRAMS<\/code> ile tan\u0131ml\u0131ysa) ve ard\u0131ndan t\u00fcm test betiklerini s\u0131rayla \u00e7al\u0131\u015ft\u0131racakt\u0131r. Her beti\u011fin \u00e7\u0131k\u0131\u015f kodu 0 ise test ba\u015far\u0131l\u0131, aksi takdirde ba\u015far\u0131s\u0131z say\u0131l\u0131r.<\/p>\n\u0130leri D\u00fczey Konular: Paralel Test \u00c7al\u0131\u015ft\u0131rma ve Raporlama<\/h2>\n
Paralel Test \u00c7al\u0131\u015ft\u0131rma<\/h3>\n
make<\/code> program\u0131n\u0131n yerle\u015fik bir \u00f6zelli\u011fidir. Tek yapman\u0131z gereken, make check<\/code> komutunu -j N<\/code> bayra\u011f\u0131yla \u00e7al\u0131\u015ft\u0131rmakt\u0131r. Burada N<\/code>, ayn\u0131 anda \u00e7al\u0131\u015ft\u0131r\u0131lacak i\u015f par\u00e7ac\u0131\u011f\u0131 veya i\u015flem say\u0131s\u0131n\u0131 temsil eder.<\/p>\n\nmake -j 8 check\n<\/pre>\nmake<\/code>'in 8 testi veya derleme i\u015fini ayn\u0131 anda \u00e7al\u0131\u015ft\u0131rmas\u0131na izin verir. Ancak, paralel test \u00e7al\u0131\u015ft\u0131rman\u0131n sorunsuz olmas\u0131 i\u00e7in baz\u0131 \u00f6n ko\u015fullar vard\u0131r:<\/p>\n\n
mktemp -d<\/code> kullanarak her test i\u00e7in benzersiz bir ge\u00e7ici dizin olu\u015fturun. Test sonunda bu dizini temizleyin (rm -rf \"$TEST_DIR\"<\/code>). Bu, testlerin paralel \u00e7al\u0131\u015f\u0131rken birbirlerini etkilememesini garanti eden en iyi uygulamad\u0131r.\n<\/div>\nTest Raporlama<\/h3>\n
make check<\/code> \u00e7\u0131kt\u0131s\u0131 genellikle test betiklerinin standart \u00e7\u0131kt\u0131lar\u0131n\u0131 g\u00f6sterir ve ba\u015far\u0131s\u0131z olan testleri belirtir. Bu temel durumlar i\u00e7in yeterli olsa da, \u00f6zellikle s\u00fcrekli entegrasyon (CI) sistemlerinde veya b\u00fcy\u00fck test s\u00fcitlerinde daha yap\u0131land\u0131r\u0131lm\u0131\u015f bir rapora ihtiya\u00e7 duyulabilir.<\/p>\n1. Basit Raporlama<\/h4>\n
make check<\/code> bu durumu \u00f6zetleyecektir. Ba\u015far\u0131s\u0131z olan testlerin \u00e7\u0131kt\u0131lar\u0131 genellikle konsolda g\u00f6sterilir.<\/p>\n2. Yap\u0131land\u0131r\u0131lm\u0131\u015f Raporlar (TAP veya JUnit)<\/h4>\n
\n
\n# Python ile JUnit XML \u00e7\u0131kt\u0131s\u0131 \u00fcretimi i\u00e7in basit bir \u00f6rnek\n# generate_junit_report.py\nimport sys\nimport xml.etree.ElementTree as ET\n\ndef generate_report(test_name, success, message=\"\"):\n testsuite = ET.Element(\"testsuite\", name=test_name, tests=\"1\", failures=\"0\")\n testcase = ET.SubElement(testsuite, \"testcase\", name=test_name)\n if not success:\n testsuite.set(\"failures\", \"1\")\n failure = ET.SubElement(testcase, \"failure\", message=\"Test Failed\")\n failure.text = message\n \n tree = ET.ElementTree(testsuite)\n ET.indent(tree, space=\" \", level=0) # Pretty print\n return ET.tostring(testsuite, encoding=\"unicode\")\n\nif __name__ == \"__main__\":\n if len(sys.argv) < 3:\n print(\"Kullan\u0131m: python generate_junit_report.py 3. CI\/CD Entegrasyonu<\/h4>\n
\n
.\/configure<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131n.<\/li>\nmake<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131n.<\/li>\nmake check<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131n. Paralel \u00e7al\u0131\u015ft\u0131rmak i\u00e7in make -j N check<\/code> kullanabilirsiniz.<\/li>\n\n# .github\/workflows\/ci.yml (GitHub Actions \u00f6rne\u011fi)\nname: Autotools CI\n\non: [push, pull_request]\n\njobs:\n build-and-test:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v3\n - name: Kurulum\n run: |\n sudo apt-get update\n sudo apt-get install -y autoconf automake build-essential\n - name: Yap\u0131land\u0131rma\n run: |\n autoreconf -fis\n .\/configure\n - name: Derleme\n run: make\n - name: Test Etme\n run: make -j$(nproc) check\n # JUnit raporlar\u0131n\u0131 toplamak i\u00e7in (e\u011fer testleriniz JUnit \u00e7\u0131kt\u0131s\u0131 \u00fcretiyorsa)\n - name: Test Raporlar\u0131n\u0131 Y\u00fckle\n uses: actions\/upload-artifact@v3\n if: always()\n with:\n name: test-results\n path: tests\/*.xml # Testlerinizin \u00fcretti\u011fi XML dosyalar\u0131\n<\/pre>\nS\u0131k\u00e7a Kar\u015f\u0131la\u015f\u0131lan Sorunlar ve \u00c7\u00f6z\u00fcmleri<\/h2>\n
Sorun 1: \"make check\" Testleri Bulam\u0131yor veya \u00c7al\u0131\u015ft\u0131ram\u0131yor<\/h3>\n
make check<\/code> komutu \u00e7al\u0131\u015f\u0131yor ancak hi\u00e7bir test beti\u011fini \u00e7al\u0131\u015ft\u0131rm\u0131yor veya \"No tests to run\" gibi bir mesaj veriyor.<\/p>\n\n
tests\/Makefile<\/code> Olu\u015fturulmam\u0131\u015f:<\/b> configure.ac<\/code> dosyan\u0131zda AC_OUTPUT(Makefile tests\/Makefile)<\/code> sat\u0131r\u0131n\u0131n oldu\u011fundan ve autoreconf -fis && .\/configure<\/code> ad\u0131mlar\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zdan emin olun.<\/li>\nSUBDIRS<\/code> Tan\u0131ml\u0131 De\u011fil:<\/b> Ana Makefile.am<\/code> dosyan\u0131zda SUBDIRS = . tests<\/code> (veya benzeri bir tan\u0131m\u0131n) mevcut oldu\u011fundan emin olun.<\/li>\ncheck_SCRIPTS<\/code> Tan\u0131ml\u0131 De\u011fil:<\/b> tests\/Makefile.am<\/code> dosyas\u0131nda test betiklerinizi check_SCRIPTS = test1.sh test2.sh<\/code> \u015feklinde do\u011fru bir \u015fekilde tan\u0131mlad\u0131\u011f\u0131n\u0131zdan emin olun.<\/li>\n.sh<\/code> dosyas\u0131) y\u00fcr\u00fctme izinlerine sahip oldu\u011fundan emin olun: chmod +x tests\/test_script.sh<\/code>.<\/li>\n<\/ul>\nSorun 2: Testler Ba\u015far\u0131s\u0131z Oluyor Ancak Hata Mesajlar\u0131 Yetersiz<\/h3>\n
\n