Modern yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde, her bir kod de\u011fi\u015fikli\u011finin (Pull Request – PR) otomatik testlerden ve entegrasyon kontrollerinden ge\u00e7mesi standart bir uygulamad\u0131r. Ancak bu s\u00fcre\u00e7, \u00e7o\u011fu zaman geli\u015ftiriciler i\u00e7in sinir bozucu bir bekleme ve d\u00fczeltme d\u00f6ng\u00fcs\u00fcne d\u00f6n\u00fc\u015febilir. Bir PR g\u00f6nderirsiniz, CI (S\u00fcrekli Entegrasyon) sistemi devreye girer, saatler s\u00fcren testler \u00e7al\u0131\u015f\u0131r ve sonunda bir veya daha fazla testin k\u0131r\u0131ld\u0131\u011f\u0131 haberiyle kar\u015f\u0131la\u015f\u0131rs\u0131n\u0131z. Bu durum, sadece geli\u015ftiricinin zaman\u0131n\u0131 \u00e7almakla kalmaz, ayn\u0131 zamanda CI\/CD (S\u00fcrekli Entegrasyon\/S\u00fcrekli Teslimat) hatt\u0131n\u0131n verimlili\u011fini d\u00fc\u015f\u00fcr\u00fcr ve tak\u0131m\u0131n genel motivasyonunu olumsuz etkiler. Peki, bu bekleme ve d\u00fczeltme d\u00f6ng\u00fcs\u00fcn\u00fc k\u0131rman\u0131n bir yolu var m\u0131? CI \u00e7al\u0131\u015fmaya ba\u015flamadan \u00f6nce, yazd\u0131\u011f\u0131n\u0131z kodun hangi testleri k\u0131rabilece\u011fini \u00f6ng\u00f6rebilmek, geli\u015ftirme s\u00fcrecini k\u00f6kten de\u011fi\u015ftirebilir. \u0130\u015fte bu makalede, kod de\u011fi\u015fikliklerinizin potansiyel etkilerini CI s\u00fcreci ba\u015flamadan \u00f6nce nas\u0131l tespit edebilece\u011finizi, hangi stratejileri ve ara\u00e7lar\u0131 kullanabilece\u011finizi detayl\u0131 bir \u015fekilde inceleyece\u011fiz. Amac\u0131m\u0131z, daha h\u0131zl\u0131 geri bildirim d\u00f6ng\u00fcleri olu\u015fturarak, kod kalitesini art\u0131rmak ve geli\u015ftirici verimlili\u011fini maksimize etmektir. Bu sayede, her PR’\u0131n\u0131z\u0131n CI’da sorunsuz bir \u015fekilde ge\u00e7ece\u011finden emin olabilir, b\u00f6ylece hem kendinizin hem de tak\u0131m\u0131n\u0131z\u0131n de\u011ferli zaman\u0131ndan tasarruf edebilirsiniz. Bu yakla\u015f\u0131mlar, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k kod tabanlar\u0131na sahip projelerde, geli\u015ftirme h\u0131z\u0131n\u0131 ve g\u00fcvenilirli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rma potansiyeline sahiptir.<\/p>\n
Geli\u015ftiricilerin kar\u015f\u0131la\u015ft\u0131\u011f\u0131 bu yayg\u0131n problem, asl\u0131nda yaz\u0131l\u0131m m\u00fchendisli\u011finin temel zorluklar\u0131ndan biridir: De\u011fi\u015fimin etkisini y\u00f6netmek. Bir kod par\u00e7as\u0131nda yap\u0131lan k\u00fc\u00e7\u00fck bir de\u011fi\u015fiklik bile, projenin farkl\u0131 yerlerinde beklenmedik yan etkilere yol a\u00e7abilir. Bu yan etkiler, \u00e7o\u011fu zaman otomatik testler sayesinde ortaya \u00e7\u0131kar. Ancak CI ortam\u0131nda testlerin \u00e7al\u0131\u015fmas\u0131n\u0131 beklemek, pahal\u0131 bir \u00f6\u011frenme s\u00fcreci olabilir. \u00d6zellikle \u00e7ok say\u0131da testin oldu\u011fu projelerde, t\u00fcm test s\u00fcitinin \u00e7al\u0131\u015fmas\u0131 dakikalar, hatta saatler s\u00fcrebilir. Bu uzun bekleme s\u00fcreleri, geli\u015ftiricilerin dikkatini da\u011f\u0131tabilir ve ba\u011flam de\u011fi\u015fimine neden olabilir. K\u0131r\u0131lan bir testle geri d\u00f6nen bir PR, geli\u015ftiricinin o anki g\u00f6revinden uzakla\u015farak eski koduna d\u00f6nmesini gerektirir. Bu da hem zaman kayb\u0131 hem de bili\u015fsel y\u00fck anlam\u0131na gelir. Bu nedenle, CI \u00f6ncesinde test k\u0131r\u0131lmalar\u0131n\u0131 \u00f6ng\u00f6rmek, sadece teknik bir avantaj de\u011fil, ayn\u0131 zamanda geli\u015ftirici deneyimini ve genel i\u015f ak\u0131\u015f\u0131n\u0131 iyile\u015ftiren stratejik bir yakla\u015f\u0131md\u0131r. Bu makale boyunca, bu \u00f6ng\u00f6r\u00fcy\u00fc nas\u0131l kazanabilece\u011finizi ad\u0131m ad\u0131m ele alaca\u011f\u0131z.<\/p>\n
Konuya daha derinlemesine dalmadan \u00f6nce, S\u00fcrekli Entegrasyon (CI) ve S\u00fcrekli Teslimat\/Da\u011f\u0131t\u0131m (CD) kavramlar\u0131n\u0131n ve otomasyon testlerinin temel dinamiklerini anlamak \u00f6nemlidir. CI, geli\u015ftiricilerin kodlar\u0131n\u0131 d\u00fczenli olarak, genellikle g\u00fcnde birka\u00e7 kez, payla\u015f\u0131lan bir depoya entegre etmelerini gerektiren bir yaz\u0131l\u0131m geli\u015ftirme uygulamas\u0131d\u0131r. Her entegrasyon, otomatik bir derleme ve test s\u00fcreci taraf\u0131ndan do\u011frulan\u0131r. Bu, entegrasyon sorunlar\u0131n\u0131n erken tespit edilmesini sa\u011flar. CD ise, CI’\u0131n bir uzant\u0131s\u0131d\u0131r ve kod de\u011fi\u015fikliklerinin otomatik olarak test edilip da\u011f\u0131t\u0131ma haz\u0131r hale getirilmesini hedefler. Bu s\u00fcre\u00e7lerin merkezinde, kod kalitesini ve i\u015flevselli\u011fini garanti eden otomatik testler yer al\u0131r. Otomatik testler, yaz\u0131l\u0131m geli\u015ftirme ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn ayr\u0131lmaz bir par\u00e7as\u0131d\u0131r ve \u00fc\u00e7 ana kategoriye ayr\u0131l\u0131r: birim testleri, entegrasyon testleri ve u\u00e7tan uca (end-to-end) testler.<\/p>\n
Birim testleri (Unit Tests), kodun en k\u00fc\u00e7\u00fck, izole edilebilir par\u00e7alar\u0131n\u0131 (fonksiyonlar, metotlar, s\u0131n\u0131flar) test eder. Ama\u00e7, her bir birimin beklenen \u015fekilde \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olmakt\u0131r. Bu testler genellikle \u00e7ok h\u0131zl\u0131 \u00e7al\u0131\u015f\u0131r ve geli\u015ftirme s\u00fcrecinin erken a\u015famalar\u0131nda yaz\u0131l\u0131r. Birim testleri, bir fonksiyonun belirli bir girdi i\u00e7in do\u011fru \u00e7\u0131kt\u0131y\u0131 verip vermedi\u011fini veya bir s\u0131n\u0131f\u0131n metodlar\u0131n\u0131n do\u011fru davran\u0131p davranmad\u0131\u011f\u0131n\u0131 kontrol eder. Entegrasyon testleri (Integration Tests) ise, birden fazla birimin birbiriyle veya d\u0131\u015f sistemlerle (veritabanlar\u0131, API’ler, mesaj kuyruklar\u0131) do\u011fru \u015fekilde etkile\u015fim kurup kurmad\u0131\u011f\u0131n\u0131 do\u011frular. Bu testler, birim testlerinden daha yava\u015f olabilir \u00e7\u00fcnk\u00fc ger\u00e7ek ba\u011f\u0131ml\u0131l\u0131klar\u0131 i\u00e7erirler. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n kaydolma s\u00fcrecini test eden bir entegrasyon testi, hem kullan\u0131c\u0131 kay\u0131t fonksiyonunu hem de veritaban\u0131na yazma i\u015flemini kontrol edebilir. Son olarak, u\u00e7tan uca testler (End-to-End Tests), uygulaman\u0131n tamam\u0131n\u0131, kullan\u0131c\u0131n\u0131n ger\u00e7ek bir senaryoda uygulaman\u0131zla etkile\u015fim kurdu\u011fu gibi test eder. Bu testler, kullan\u0131c\u0131 aray\u00fcz\u00fcnden veritaban\u0131na kadar t\u00fcm sistemin do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olur. U\u00e7tan uca testler en yava\u015f ve en k\u0131r\u0131lgan test t\u00fcr\u00fcd\u00fcr, ancak uygulaman\u0131n genel sa\u011fl\u0131\u011f\u0131 hakk\u0131nda en kapsaml\u0131 geri bildirimi sa\u011flarlar.<\/p>\n
Testlerin k\u0131r\u0131lmas\u0131n\u0131n bir\u00e7ok nedeni olabilir. En yayg\u0131n nedenlerden biri, kodda yap\u0131lan bir de\u011fi\u015fikli\u011fin, beklenen davran\u0131\u015flar\u0131 de\u011fi\u015ftirmesi veya yeni hatalar \u00fcretmesidir. \u00d6rne\u011fin, bir fonksiyondaki parametre s\u0131ras\u0131n\u0131 de\u011fi\u015ftirmek veya bir veritaban\u0131 \u015femas\u0131n\u0131 g\u00fcncellemek, ilgili testlerin ba\u015far\u0131s\u0131z olmas\u0131na yol a\u00e7abilir. Ba\u011f\u0131ml\u0131l\u0131k de\u011fi\u015fiklikleri de test k\u0131r\u0131lmalar\u0131na neden olabilir; bir k\u00fct\u00fcphanenin veya API’nin g\u00fcncellenmesi, onunla etkile\u015fim kuran kodun ve dolay\u0131s\u0131yla testlerin bozulmas\u0131na yol a\u00e7abilir. \u00c7evre farkl\u0131l\u0131klar\u0131 da \u00f6nemli bir fakt\u00f6rd\u00fcr; geli\u015ftiricinin yerel ortam\u0131nda \u00e7al\u0131\u015fan bir testin, CI ortam\u0131nda farkl\u0131 yap\u0131land\u0131rmalar veya ba\u011f\u0131ml\u0131l\u0131klar nedeniyle ba\u015far\u0131s\u0131z olmas\u0131 m\u00fcmk\u00fcnd\u00fcr. Ayr\u0131ca, testlerin kendisinin k\u00f6t\u00fc yaz\u0131lm\u0131\u015f olmas\u0131, yani k\u0131r\u0131lgan testler (flaky tests) olmas\u0131 da sorun yaratabilir. Bu testler, bazen ge\u00e7er, bazen ba\u015far\u0131s\u0131z olur ve bu da g\u00fcvenilirli\u011fi d\u00fc\u015f\u00fcr\u00fcr. Bu temel kavramlar\u0131 anlamak, CI \u00f6ncesi test k\u0131r\u0131lmalar\u0131n\u0131 \u00f6ng\u00f6rme ve \u00f6nleme stratejilerini daha etkili bir \u015fekilde uygulaman\u0131n ilk ad\u0131m\u0131d\u0131r. Geli\u015ftirme s\u00fcrecinin “sola kayd\u0131r\u0131lmas\u0131” (shift left) prensibi, sorunlar\u0131n m\u00fcmk\u00fcn oldu\u011funca erken tespit edilmesi gerekti\u011fini vurgular; bu da testlerin yerel ortamda, CI’a ula\u015fmadan \u00f6nce \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131n\u0131 ve hatalar\u0131n orada yakalanmas\u0131n\u0131 te\u015fvik eder.<\/p>\n
CI d\u00f6ng\u00fcs\u00fcn\u00fcn maliyetini d\u00fc\u015f\u00fcrmenin ve geli\u015ftirici verimlili\u011fini art\u0131rman\u0131n en etkili yollar\u0131ndan biri, test k\u0131r\u0131lmalar\u0131n\u0131 m\u00fcmk\u00fcn oldu\u011funca erken, yani yerel geli\u015ftirme ortam\u0131n\u0131zda tespit etmektir. Bu “sola kayd\u0131rma” (shift left) yakla\u015f\u0131m\u0131, sorunlar\u0131 CI ortam\u0131na g\u00f6ndermeden \u00f6nce kendi makinenizde yakalaman\u0131z\u0131 sa\u011flar. Peki, yerel ortamda hangi proaktif ad\u0131mlar\u0131 atabiliriz? \u00d6ncelikle, yazd\u0131\u011f\u0131n\u0131z kodun ilgili birim ve entegrasyon testlerini d\u00fczenli olarak \u00e7al\u0131\u015ft\u0131rmak vazge\u00e7ilmezdir. \u00c7o\u011fu modern geli\u015ftirme ortam\u0131 ve test \u00e7er\u00e7evesi (framework), bu i\u015flemi kolayla\u015ft\u0131ran komutlar sunar. \u00d6rne\u011fin, JavaScript projelerinde Jest veya Vitest kullan\u0131yorsan\u0131z, Yerel test \u00e7al\u0131\u015ft\u0131rmalar\u0131n\u0131n yan\u0131 s\u0131ra, kod kalitesini art\u0131rmak ve yayg\u0131n hatalar\u0131 otomatik olarak tespit etmek i\u00e7in linter ve formatter (bi\u00e7imlendirici) ara\u00e7lar\u0131 kullanmak da b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Linter’lar (\u00f6rne\u011fin ESLint, Pylint), kodunuzu \u00f6nceden tan\u0131mlanm\u0131\u015f kurallara g\u00f6re analiz eder ve potansiyel hatalar\u0131, stil ihlallerini veya anti-pattern’leri tespit eder. Bu ara\u00e7lar, sadece sentaks hatalar\u0131n\u0131 de\u011fil, ayn\u0131 zamanda daha karma\u015f\u0131k mant\u0131k hatalar\u0131n\u0131 veya performans sorunlar\u0131n\u0131 da i\u015faret edebilir. Formatter’lar (\u00f6rne\u011fin Prettier, Black), kodunuzu otomatik olarak belirli bir stil k\u0131lavuzuna g\u00f6re bi\u00e7imlendirerek kod taban\u0131nda tutarl\u0131l\u0131\u011f\u0131 sa\u011flar. Bu ara\u00e7lar\u0131n kullan\u0131m\u0131, kod inceleme s\u00fcre\u00e7lerinde stil tart\u0131\u015fmalar\u0131n\u0131 azalt\u0131r ve geli\u015ftiricilerin daha \u00f6nemli konulara odaklanmas\u0131na olanak tan\u0131r. Her iki ara\u00e7 da, kodunuzu CI’a g\u00f6ndermeden \u00f6nce temiz ve tutarl\u0131 olmas\u0131n\u0131 sa\u011flayarak, potansiyel yap\u0131land\u0131rma veya stil kaynakl\u0131 CI hatalar\u0131n\u0131n \u00f6n\u00fcne ge\u00e7er.<\/p>\n Statik kod analizi ara\u00e7lar\u0131 da (\u00f6rne\u011fin SonarQube, Bandit, Checkstyle) proaktif yakla\u015f\u0131mlar\u0131n \u00f6nemli bir par\u00e7as\u0131d\u0131r. Bu ara\u00e7lar, kodunuzu \u00e7al\u0131\u015ft\u0131rmadan, sadece kaynak kodunu inceleyerek g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131, kod kokular\u0131n\u0131, karma\u015f\u0131kl\u0131\u011f\u0131 ve di\u011fer kalite sorunlar\u0131n\u0131 tespit eder. Linter’lardan daha kapsaml\u0131d\u0131rlar ve genellikle daha derinlemesine analizler yaparlar. \u00d6rne\u011fin, g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 belirleyebilir, potansiyel bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 i\u015faret edebilir veya karma\u015f\u0131k algoritmalar\u0131 basitle\u015ftirme \u00f6nerileri sunabilirler. Bu t\u00fcr ara\u00e7lar\u0131 geli\u015ftirme ortam\u0131n\u0131za entegre etmek, kodunuzu daha g\u00fcvenli, daha s\u00fcrd\u00fcr\u00fclebilir ve daha performansl\u0131 hale getirmenin yan\u0131 s\u0131ra, CI s\u00fcrecinde bu t\u00fcr sorunlardan kaynaklanabilecek test k\u0131r\u0131lmalar\u0131n\u0131 da \u00f6nler. Son olarak, pre-commit hook’lar, Git i\u015f ak\u0131\u015f\u0131n\u0131z\u0131n ayr\u0131lmaz bir par\u00e7as\u0131 olmal\u0131d\u0131r. Husky (JavaScript) veya Ve Bu yap\u0131land\u0131rma, sadece commit edilen dosyalar\u0131 analiz ederek hem zaman kazand\u0131r\u0131r hem de kod taban\u0131n\u0131n genel kalitesini s\u00fcrekli olarak y\u00fcksek tutar. Bu proaktif yakla\u015f\u0131mlar\u0131n t\u00fcm\u00fc, geli\u015ftiricilere an\u0131nda geri bildirim sa\u011flayarak, CI ortam\u0131nda kar\u015f\u0131la\u015f\u0131lacak s\u00fcrprizleri en aza indirir ve daha sorunsuz bir geli\u015ftirme s\u00fcreci sunar.<\/p>\n B\u00fcy\u00fck projelerde her PR i\u00e7in t\u00fcm test s\u00fcitini \u00e7al\u0131\u015ft\u0131rmak, hem zaman hem de kaynak a\u00e7\u0131s\u0131ndan olduk\u00e7a maliyetli olabilir. Bu durum, \u00f6zellikle y\u00fczlerce veya binlerce testin oldu\u011fu projelerde, geli\u015ftirme h\u0131z\u0131n\u0131 ciddi \u015fekilde yava\u015flat\u0131r. \u0130\u015fte bu noktada “ak\u0131ll\u0131 test se\u00e7imi” veya “de\u011fi\u015fiklik odakl\u0131 test \u00e7al\u0131\u015ft\u0131rma” stratejileri devreye girer. Bu yakla\u015f\u0131mlar, sadece de\u011fi\u015fen kodla do\u011frudan veya dolayl\u0131 olarak ili\u015fkili testleri \u00e7al\u0131\u015ft\u0131rmay\u0131 hedefler. Peki, bu nas\u0131l m\u00fcmk\u00fcn olabilir ve hangi ara\u00e7lar bize yard\u0131mc\u0131 olur?<\/p>\n Ak\u0131ll\u0131 test se\u00e7iminin temelinde, kod de\u011fi\u015fikliklerinin etkile\u015fim haritas\u0131n\u0131 \u00e7\u0131karmak yatar. Bir dosyadaki de\u011fi\u015fiklik, hangi di\u011fer dosyalar\u0131, s\u0131n\u0131flar\u0131 veya fonksiyonlar\u0131 etkileyebilir? Bu sorunun cevab\u0131n\u0131 bulmak i\u00e7in \u00e7e\u015fitli y\u00f6ntemler kullan\u0131l\u0131r. En basit yakla\u015f\u0131m, \u00c7o\u011fu modern test \u00e7er\u00e7evesi, bu t\u00fcr ak\u0131ll\u0131 test se\u00e7imini destekleyen yerle\u015fik \u00f6zelliklere sahiptir. \u00d6rne\u011fin, JavaScript ekosisteminde pop\u00fcler olan Jest, Python d\u00fcnyas\u0131nda ise Bu stratejilerin uygulanmas\u0131, geli\u015ftiricilerin daha h\u0131zl\u0131 geri bildirim almas\u0131n\u0131 sa\u011flar ve CI\/CD hatt\u0131n\u0131n verimlili\u011fini art\u0131r\u0131r. Geli\u015ftiriciler, kodlar\u0131n\u0131 commit etmeden veya PR a\u00e7madan \u00f6nce, sadece kendi de\u011fi\u015fiklikleriyle ilgili testleri \u00e7al\u0131\u015ft\u0131rarak potansiyel k\u0131r\u0131lmalar\u0131 h\u0131zla tespit edebilirler. Bu, uzun CI bekleme s\u00fcrelerini ortadan kald\u0131r\u0131r ve geli\u015ftiricilerin ak\u0131\u015f\u0131n\u0131 korumalar\u0131na yard\u0131mc\u0131 olur. Sonu\u00e7 olarak, ak\u0131ll\u0131 test se\u00e7imi, modern yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde olmazsa olmaz bir yakla\u015f\u0131md\u0131r ve hem zaman hem de maliyet a\u00e7\u0131s\u0131ndan \u00f6nemli avantajlar sunar.<\/p>\n K\u00fc\u00e7\u00fck ve orta \u00f6l\u00e7ekli projelerde yerel test \u00e7al\u0131\u015ft\u0131rma ve basit ak\u0131ll\u0131 test se\u00e7imi yeterli olabilirken, b\u00fcy\u00fck \u00f6l\u00e7ekli ve karma\u015f\u0131k projelerde, \u00f6zellikle monorepo (tek depo) mimarilerinde, daha geli\u015fmi\u015f stratejilere ve entegrasyonlara ihtiya\u00e7 duyulur. Bu t\u00fcr projelerde, y\u00fczlerce farkl\u0131 servis veya k\u00fct\u00fcphane tek bir depoda bar\u0131nd\u0131r\u0131labilir ve bir dosyadaki k\u00fc\u00e7\u00fck bir de\u011fi\u015fiklik bile potansiyel olarak bir\u00e7ok farkl\u0131 projeyi etkileyebilir. Bu senaryolarda, manuel ba\u011f\u0131ml\u0131l\u0131k analizi yapmak veya basit B\u00fcy\u00fck \u00f6l\u00e7ekli monorepolarda, Nx veya Turborepo gibi ara\u00e7lar devreye girer. Bu ara\u00e7lar, projenin tamam\u0131n\u0131n bir ba\u011f\u0131ml\u0131l\u0131k grafi\u011fini olu\u015fturur ve bir dosyadaki de\u011fi\u015fikli\u011fin hangi di\u011fer projelere veya paketlere do\u011frudan veya dolayl\u0131 olarak etki etti\u011fini belirleyebilir. \u00d6rne\u011fin, bir yard\u0131mc\u0131 (utility) k\u00fct\u00fcphanesinde yap\u0131lan bir de\u011fi\u015fiklik, bu k\u00fct\u00fcphaneyi kullanan t\u00fcm servislerin veya uygulamalar\u0131n testlerinin \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131 gerekti\u011fini i\u015faret edebilir. Bu ara\u00e7lar, bu analizi otomatikle\u015ftirerek, sadece “etkilenen” (affected) projelerin testlerini \u00e7al\u0131\u015ft\u0131rmak i\u00e7in optimize edilmi\u015f komutlar sunar. Bu, CI s\u00fcrecinde yaln\u0131zca ger\u00e7ekten gerekli olan testlerin \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131n\u0131 sa\u011flayarak, CI s\u00fcrelerini dakikalara, hatta saniyeler d\u00fc\u015f\u00fcrebilir.<\/p>\n Bu ara\u00e7lar, ayr\u0131ca bir “computation cache” (hesaplama \u00f6nbelle\u011fi) kullanarak, daha \u00f6nce ayn\u0131 girdiyle \u00e7al\u0131\u015ft\u0131r\u0131lm\u0131\u015f testlerin veya derlemelerin sonu\u00e7lar\u0131n\u0131 \u00f6nbelle\u011fe alabilir. Bu sayede, ayn\u0131 kod \u00fczerinde yap\u0131lan tekrar eden de\u011fi\u015fikliklerde veya farkl\u0131 geli\u015ftiricilerin ayn\u0131 de\u011fi\u015fiklikleri test etmesi durumunda, testler yeniden \u00e7al\u0131\u015ft\u0131r\u0131lmak yerine \u00f6nbellekten al\u0131n\u0131r, bu da CI s\u00fcresini daha da k\u0131salt\u0131r. Bu, \u00f6zellikle b\u00fcy\u00fck tak\u0131mlar\u0131n ve s\u0131k entegrasyonlar\u0131n oldu\u011fu ortamlarda paha bi\u00e7ilmez bir \u00f6zelliktir.<\/p>\n IDE entegrasyonlar\u0131 da geli\u015ftiricilerin yerel ortamda daha verimli olmas\u0131n\u0131 sa\u011flar. Visual Studio Code, IntelliJ IDEA gibi modern IDE’ler, testleri do\u011frudan edit\u00f6r i\u00e7inden \u00e7al\u0131\u015ft\u0131rma, hata ay\u0131klama (debug) ve sonu\u00e7lar\u0131 g\u00f6rselle\u015ftirme yetenekleri sunar. Baz\u0131 IDE eklentileri, sizin kodunuzu kaydederken veya de\u011fi\u015fiklik yaparken arka planda ilgili testleri otomatik olarak \u00e7al\u0131\u015ft\u0131rarak an\u0131nda geri bildirim sa\u011flayabilir. Bu, geli\u015ftiricinin ba\u011flam de\u011fi\u015ftirmeden, yazd\u0131\u011f\u0131 kodun etkisini hemen g\u00f6rmesine olanak tan\u0131r.<\/p>\n B\u00fcy\u00fck bir e-ticaret platformu d\u00fc\u015f\u00fcnelim. Bu platform, \u00fcr\u00fcn y\u00f6netimi, kullan\u0131c\u0131 profilleri, \u00f6deme sistemleri, arama motoru gibi bir\u00e7ok mikroservisten olu\u015fuyor ve t\u00fcm kod taban\u0131 tek bir monorepo i\u00e7inde y\u00f6netiliyor. Eskiden, her PR a\u00e7\u0131ld\u0131\u011f\u0131nda, t\u00fcm mikroservislerin birim, entegrasyon ve hatta baz\u0131 u\u00e7tan uca testleri \u00e7al\u0131\u015ft\u0131r\u0131l\u0131yordu. Bu s\u00fcre\u00e7, ortalama 45 dakika s\u00fcr\u00fcyordu. G\u00fcnde ortalama 50 PR a\u00e7\u0131ld\u0131\u011f\u0131nda, CI kaynaklar\u0131 s\u00fcrekli me\u015fgul oluyor ve geli\u015ftiriciler uzun s\u00fcre beklemek zorunda kal\u0131yordu. Ekip, Nx’i benimseyerek bir ba\u011f\u0131ml\u0131l\u0131k grafi\u011fi olu\u015fturdu. Art\u0131k bir geli\u015ftirici, \u00f6rne\u011fin \u00fcr\u00fcn y\u00f6netimi servisinde bir de\u011fi\u015fiklik yapt\u0131\u011f\u0131nda, Nx sadece \u00fcr\u00fcn y\u00f6netimi servisi ve bu servise ba\u011f\u0131ml\u0131 olan (\u00f6rne\u011fin arama motoru veya kategori servisi) di\u011fer servislerin testlerini \u00e7al\u0131\u015ft\u0131r\u0131yordu. Bu entegrasyon sayesinde, ortalama CI s\u00fcresi 45 dakikadan 7 dakikaya d\u00fc\u015ft\u00fc. Ayr\u0131ca, Nx’in \u00f6nbellekleme \u00f6zelli\u011fi sayesinde, ayn\u0131 kod de\u011fi\u015fiklikleri tekrar test edildi\u011finde s\u00fcre 2 dakikaya kadar inebiliyordu. Bu, geli\u015ftirici verimlili\u011fini %30’dan fazla art\u0131r\u0131rken, test k\u0131r\u0131lmalar\u0131n\u0131n erken tespiti sayesinde canl\u0131ya \u00e7\u0131kan hatalar\u0131n say\u0131s\u0131 da \u00f6nemli \u00f6l\u00e7\u00fcde azald\u0131. Bu vaka \u00e7al\u0131\u015fmas\u0131, ak\u0131ll\u0131 test se\u00e7imi ve monorepo ara\u00e7lar\u0131n\u0131n b\u00fcy\u00fck \u00f6l\u00e7ekli projelerdeki d\u00f6n\u00fc\u015ft\u00fcr\u00fcc\u00fc etkisini a\u00e7\u0131k\u00e7a g\u00f6stermektedir.<\/p>\n Bu geli\u015fmi\u015f stratejiler, sadece CI s\u00fcrelerini k\u0131saltmakla kalmaz, ayn\u0131 zamanda geli\u015ftiricilerin daha g\u00fcvenle kod yazmas\u0131na ve daha h\u0131zl\u0131 yineleme yapmas\u0131na olanak tan\u0131r. Kod kalitesi artar, hata oran\u0131 d\u00fc\u015fer ve genel olarak daha sa\u011flam bir yaz\u0131l\u0131m geli\u015ftirme s\u00fcreci elde edilir. Bu entegrasyonlar, modern DevOps pratiklerinin temel ta\u015flar\u0131ndan biridir.<\/p>\n CI (S\u00fcrekli Entegrasyon) s\u00fcreci ba\u015flamadan \u00f6nce bir Pull Request’in (PR) hangi testleri k\u0131rabilece\u011fini \u00f6ng\u00f6rebilmek, modern yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde bir l\u00fcks olmaktan \u00e7\u0131k\u0131p temel bir gereklilik haline gelmi\u015ftir. Bu makale boyunca ele ald\u0131\u011f\u0131m\u0131z proaktif yakla\u015f\u0131mlar ve ak\u0131ll\u0131 test se\u00e7im stratejileri, geli\u015ftiricilerin de\u011ferli zaman\u0131ndan tasarruf etmelerine, CI\/CD hatt\u0131n\u0131n verimlili\u011fini art\u0131rmalar\u0131na ve en \u00f6nemlisi, daha y\u00fcksek kaliteli ve hatas\u0131z kodlar \u00fcretmelerine olanak tan\u0131r. Yerel geli\u015ftirme ortam\u0131nda testleri d\u00fczenli olarak \u00e7al\u0131\u015ft\u0131rmak, linter ve formatter ara\u00e7lar\u0131n\u0131 kullanmak, statik kod analizi yapmak ve pre-commit hook’lar\u0131 entegre etmek, sorunlar\u0131 kayna\u011f\u0131nda, yani daha kod yaz\u0131l\u0131rken yakalaman\u0131n ilk ad\u0131mlar\u0131d\u0131r. Bu “sola kayd\u0131rma” prensibi, hatalar\u0131n CI ortam\u0131na ula\u015fmadan \u00f6nce tespit edilmesini sa\u011flayarak, d\u00fczeltme maliyetini \u00f6nemli \u00f6l\u00e7\u00fcde d\u00fc\u015f\u00fcr\u00fcr.<\/p>\n Ak\u0131ll\u0131 test se\u00e7imi ara\u00e7lar\u0131 ve monorepo \u00e7\u00f6z\u00fcmleri (Nx, Turborepo gibi), \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k projelerde, sadece de\u011fi\u015fen kodla do\u011frudan veya dolayl\u0131 olarak ili\u015fkili testleri \u00e7al\u0131\u015ft\u0131rarak CI s\u00fcrelerini dramatik bir \u015fekilde k\u0131salt\u0131r. Bu sayede, geli\u015ftiriciler an\u0131nda geri bildirim alabilir, kod de\u011fi\u015fikliklerinin etkisini h\u0131zla do\u011frulayabilir ve daha h\u0131zl\u0131 yineleme yapabilirler. Bir e-ticaret platformu \u00f6rne\u011finde g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, bu t\u00fcr entegrasyonlar, CI s\u00fcrelerini dakikalardan saniyelere indirerek geli\u015ftirici verimlili\u011fini art\u0131r\u0131r ve canl\u0131ya \u00e7\u0131kan hata oran\u0131n\u0131 d\u00fc\u015f\u00fcr\u00fcr. Sonu\u00e7 olarak, bu stratejilerin benimsenmesi, sadece teknik bir optimizasyon de\u011fil, ayn\u0131 zamanda geli\u015ftirici deneyimini iyile\u015ftiren, tak\u0131m motivasyonunu art\u0131ran ve genel olarak daha sa\u011flam bir yaz\u0131l\u0131m ekosistemi olu\u015fturan k\u00fclt\u00fcrel bir de\u011fi\u015fimdir. Her geli\u015ftiricinin kendi kodunun potansiyel etkilerini CI’dan \u00f6nce \u00f6ng\u00f6rebilmesi, modern yaz\u0131l\u0131m m\u00fchendisli\u011finin temel hedeflerinden biri olmal\u0131d\u0131r.<\/p>\n Bu yakla\u015f\u0131mlar sayesinde, geli\u015ftiriciler art\u0131k PR’lar\u0131n\u0131 bir “s\u00fcrpriz kutusu” gibi CI’a g\u00f6ndermek zorunda kalmazlar. Aksine, yapt\u0131klar\u0131 de\u011fi\u015fikliklerin g\u00fcvenilirli\u011fini kendi yerel ortamlar\u0131nda b\u00fcy\u00fck \u00f6l\u00e7\u00fcde do\u011frulam\u0131\u015f olurlar. Bu durum, hem bireysel geli\u015ftirici d\u00fczeyinde hem de t\u00fcm tak\u0131m ve organizasyon d\u00fczeyinde \u00f6nemli faydalar sa\u011flar. Daha h\u0131zl\u0131 geri bildirim d\u00f6ng\u00fcleri, daha az hata, daha y\u00fcksek kod kalitesi ve sonu\u00e7ta daha mutlu geli\u015ftiriciler anlam\u0131na gelir. Bu nedenle, bu stratejileri kendi geli\u015ftirme s\u00fcre\u00e7lerinize entegre etmek, uzun vadede projenizin ba\u015far\u0131s\u0131 i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n K\u00fc\u00e7\u00fck projelerde veya kritik g\u00fcvenlik, finansal i\u015flemler gibi y\u00fcksek riskli sistemlerde, her PR i\u00e7in t\u00fcm testleri \u00e7al\u0131\u015ft\u0131rmak mant\u0131kl\u0131 olabilir. Ayr\u0131ca, projenin olgunla\u015fma a\u015famas\u0131nda, testlerin kapsam\u0131n\u0131n ve g\u00fcvenilirli\u011finin tam olarak belirlenmedi\u011fi durumlarda da bu yakla\u015f\u0131m tercih edilebilir. Ancak genellikle, zaman ve kaynak k\u0131s\u0131tlamalar\u0131 nedeniyle ak\u0131ll\u0131 test se\u00e7imi daha verimli bir alternatiftir.<\/p>\n<\/li>\n Ak\u0131ll\u0131 test se\u00e7imi ara\u00e7lar\u0131, neredeyse t\u00fcm pop\u00fcler programlama dilleri ve test framework’leri i\u00e7in mevcuttur. \u00d6rne\u011fin, JavaScript\/TypeScript i\u00e7in Jest ( Monorepo yap\u0131lar\u0131nda ba\u015flang\u0131\u00e7ta karma\u015f\u0131k g\u00f6r\u00fcnebilir, ancak Nx veya Turborepo gibi \u00f6zel ara\u00e7lar sayesinde ak\u0131ll\u0131 test se\u00e7imi ve \u00e7al\u0131\u015ft\u0131rma olduk\u00e7a kolayla\u015f\u0131r. Bu ara\u00e7lar, ba\u011f\u0131ml\u0131l\u0131k grafi\u011fi analizi ve \u00f6nbellekleme \u00f6zellikleri sayesinde monorepolar\u0131n karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 y\u00f6netmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Do\u011fru yap\u0131land\u0131rma ile CI s\u00fcrelerini \u00f6nemli \u00f6l\u00e7\u00fcde azaltabilirler.<\/p>\n<\/li>\n K\u00fc\u00e7\u00fck projeler i\u00e7in t\u00fcm geli\u015fmi\u015f stratejilere ihtiya\u00e7 duyulmayabilir. Ancak yerel test \u00e7al\u0131\u015ft\u0131rma, linter\/formatter kullan\u0131m\u0131 ve pre-commit hook’lar gibi temel proaktif yakla\u015f\u0131mlar, projenin b\u00fcy\u00fckl\u00fc\u011f\u00fcnden ba\u011f\u0131ms\u0131z olarak her zaman faydal\u0131d\u0131r. Bu temel ad\u0131mlar, kod kalitesini art\u0131r\u0131r ve gelecekte projenin b\u00fcy\u00fcmesi durumunda iyi bir temel olu\u015fturur.<\/p>\n<\/li>\n Test kapsam\u0131 (code coverage), kodunuzun ne kadar\u0131n\u0131n testler taraf\u0131ndan y\u00fcr\u00fct\u00fcld\u00fc\u011f\u00fcn\u00fc g\u00f6steren \u00f6nemli bir metriktir. Jest, Pytest-cov, JaCoCo gibi ara\u00e7lar, test kapsam\u0131 raporlar\u0131 olu\u015fturman\u0131za olanak tan\u0131r. Bu raporlar\u0131 CI s\u00fcrecinize entegre edebilir ve belirli bir kapsam e\u015fi\u011finin alt\u0131na d\u00fc\u015f\u00fcld\u00fc\u011f\u00fcnde CI’\u0131 ba\u015far\u0131s\u0131z hale getirebilirsiniz. Ancak unutulmamal\u0131d\u0131r ki, y\u00fcksek test kapsam\u0131 tek ba\u015f\u0131na kod kalitesini garanti etmez; testlerin kalitesi ve anlaml\u0131l\u0131\u011f\u0131 da \u00f6nemlidir.<\/p>\n<\/li>\n<\/ul>\n #Yaz\u0131l\u0131mGeli\u015ftirme #TestOtomasyonu #CI\/CD #KodKalitesi #DevOps<\/p>\n","protected":false},"excerpt":{"rendered":"Modern yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde, her bir kod de\u011fi\u015fikli\u011finin (Pull Request – PR) otomatik testlerden ve entegrasyon kontrollerinden ge\u00e7mesi standart bir uygulamad\u0131r.","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-43029","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nnpm test<\/code> veya yarn test<\/code> komutlar\u0131 ile t\u00fcm testleri veya sadece de\u011fi\u015fen dosyalarla ilgili testleri \u00e7al\u0131\u015ft\u0131rabilirsiniz. Python projelerinde Pytest i\u00e7in pytest<\/code>, Java projelerinde Maven i\u00e7in mvn test<\/code> gibi komutlar mevcuttur. Bu komutlar\u0131 kodunuzu yazarken s\u0131k s\u0131k \u00e7al\u0131\u015ft\u0131rmak, an\u0131nda geri bildirim alman\u0131z\u0131 ve potansiyel hatalar\u0131 h\u0131zla d\u00fczeltmenizi sa\u011flar.<\/p>\npre-commit<\/code> framework’\u00fc (Python) gibi ara\u00e7larla yap\u0131land\u0131r\u0131labilen bu hook’lar, siz kodunuzu commit etmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131zda belirli komutlar\u0131 (\u00f6rne\u011fin linter’lar\u0131 \u00e7al\u0131\u015ft\u0131rma, testleri \u00e7al\u0131\u015ft\u0131rma, kod bi\u00e7imlendirme) otomatik olarak tetikler. Bu sayede, hatal\u0131 veya stil kurallar\u0131na uymayan kodun depoya girmesi engellenir. A\u015fa\u011f\u0131daki \u00f6rnek, bir JavaScript projesinde Husky ve lint-staged kullanarak sadece de\u011fi\u015fen dosyalar \u00fczerinde lint ve format i\u015flemlerini \u00e7al\u0131\u015ft\u0131ran bir .husky\/pre-commit<\/code> yap\u0131land\u0131rmas\u0131n\u0131 g\u00f6stermektedir:<\/p>\n#!\/bin\/sh\n. \"$(dirname \"$0\")\/_\/husky.sh\"\n\nnpx lint-staged<\/code><\/pre>\n<\/p><\/div>\npackage.json<\/code> dosyas\u0131nda lint-staged<\/code> yap\u0131land\u0131rmas\u0131:<\/p>\n{\n \"lint-staged\": {\n \"*.{js,jsx,ts,tsx}\": [\n \"eslint --fix\",\n \"prettier --write\",\n \"jest --findRelatedTests\"\n ],\n \"*.{json,css,md}\": [\n \"prettier --write\"\n ]\n }\n}<\/code><\/pre>\n<\/p><\/div>\nAk\u0131ll\u0131 Test Se\u00e7imi ve \u00c7al\u0131\u015ft\u0131rma: Sadece \u0130lgili Testleri \u00c7al\u0131\u015ft\u0131rmak M\u00fcmk\u00fcn m\u00fcd\u00fcr?<\/h2>\n
git diff<\/code> komutunu kullanarak de\u011fi\u015ftirilen dosyalar\u0131 tespit etmek ve bu dosyalarla ayn\u0131 dizinde veya mant\u0131ksal olarak ili\u015fkili test dosyalar\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rmakt\u0131r. Ancak bu y\u00f6ntem, ba\u011f\u0131ml\u0131l\u0131klar\u0131 tam olarak yans\u0131tmayabilir. Daha sofistike yakla\u015f\u0131mlar, kod taban\u0131n\u0131n ba\u011f\u0131ml\u0131l\u0131k grafi\u011fini analiz eder. Bir mod\u00fcldeki de\u011fi\u015fiklik, o mod\u00fcl\u00fc kullanan di\u011fer mod\u00fclleri ve dolay\u0131s\u0131yla o mod\u00fcllerle ilgili testleri de etkileyebilir. Bu t\u00fcr analizler, genellikle statik kod analizi teknikleri veya \u00f6zel test ara\u00e7lar\u0131 taraf\u0131ndan ger\u00e7ekle\u015ftirilir.<\/p>\n--findRelatedTests<\/code> bayra\u011f\u0131 ile bu i\u015flevi sunar. Bu bayrak, belirli bir veya daha fazla dosya verildi\u011finde, bu dosyalarla ili\u015fkili t\u00fcm testleri bulur ve \u00e7al\u0131\u015ft\u0131r\u0131r. Bu, geli\u015ftiricinin sadece \u00fczerinde \u00e7al\u0131\u015ft\u0131\u011f\u0131 dosyalar\u0131 belirterek, t\u00fcm test s\u00fcitini \u00e7al\u0131\u015ft\u0131rmak zorunda kalmadan ilgili testleri h\u0131zl\u0131ca do\u011frulamas\u0131na olanak tan\u0131r. A\u015fa\u011f\u0131daki \u00f6rnek, Jest ile nas\u0131l kullan\u0131labilece\u011fini g\u00f6sterir:<\/p>\n# Sadece de\u011fi\u015fen 'src\/utils\/math.js' dosyas\u0131yla ili\u015fkili testleri \u00e7al\u0131\u015ft\u0131r\nnpx jest --findRelatedTests src\/utils\/math.js\n\n# Git'teki son commit'te de\u011fi\u015fen dosyalarla ili\u015fkili testleri \u00e7al\u0131\u015ft\u0131r (pre-commit hook'larda faydal\u0131)\nnpx jest --findRelatedTests $(git diff --name-only HEAD~1)<\/code><\/pre>\n<\/p><\/div>\npytest-picked<\/code> gibi eklentiler, Git’teki de\u011fi\u015fen dosyalara g\u00f6re ilgili testleri se\u00e7me yetene\u011fi sunar. Java projelerinde Maven Surefire eklentisi veya Gradle gibi derleme ara\u00e7lar\u0131, baz\u0131 durumlarda de\u011fi\u015fen kaynak kodlar\u0131na g\u00f6re testleri yeniden \u00e7al\u0131\u015ft\u0131rma mant\u0131\u011f\u0131na sahip olabilir. Ancak genellikle daha manuel konfig\u00fcrasyon veya \u00f6zel scriptler gerektirebilir. Monorepo (tek depo) yap\u0131lar\u0131nda bu t\u00fcr ak\u0131ll\u0131 test se\u00e7imi daha da kritik hale gelir. Nx veya Turborepo gibi monorepo ara\u00e7lar\u0131, ba\u011f\u0131ml\u0131l\u0131k grafiklerini kullanarak hangi projenin veya paketin etkilendi\u011fini otomatik olarak belirleyebilir ve sadece etkilenen projelerin testlerini \u00e7al\u0131\u015ft\u0131rabilir. Bu, b\u00fcy\u00fck monorepolarda CI s\u00fcresini dramatik bir \u015fekilde azaltabilir.<\/p>\nGeli\u015fmi\u015f Stratejiler ve Entegrasyonlar: B\u00fcy\u00fck \u00d6l\u00e7ekli Projelerde Test Y\u00f6netimi<\/h2>\n
git diff<\/code> tabanl\u0131 test se\u00e7imleri yetersiz kal\u0131r.<\/p>\n# Nx ile de\u011fi\u015fen projelerin testlerini \u00e7al\u0131\u015ft\u0131rma\nnpx nx affected:test --base=main --head=HEAD\n\n# Turborepo ile de\u011fi\u015fen projelerin testlerini \u00e7al\u0131\u015ft\u0131rma (pipeline'da cache kullanarak)\nnpx turbo run test --filter=\"[HEAD^1]...\"<\/code><\/pre>\n<\/p><\/div>\nVaka \u00c7al\u0131\u015fmas\u0131: Bir E-ticaret Platformunun Deneyimi<\/h3>\n
Sonu\u00e7: Daha H\u0131zl\u0131 Geri Bildirim, Daha Y\u00fcksek Kaliteli Kod ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
\n
--findRelatedTests<\/code>), Python i\u00e7in Pytest (pytest-picked<\/code> eklentisi), Java i\u00e7in Maven veya Gradle ile \u00f6zel scriptler ve monorepo ara\u00e7lar\u0131 (Nx, Turborepo) arac\u0131l\u0131\u011f\u0131yla kullan\u0131labilir. Bu ara\u00e7lar\u0131n \u00e7o\u011fu, Git de\u011fi\u015fikliklerini temel alarak \u00e7al\u0131\u015f\u0131r ve bu nedenle dil veya framework’ten ba\u011f\u0131ms\u0131z olarak bir \u015fekilde uygulanabilir.<\/p>\n<\/li>\n