Artik kodu yapay zeka yaziyor, bunu kabul ettik. Peki biz yazilimci olarak isin neresindeyiz? Bunu burada uzun uzun anlatmak istemiyorum. Yazilimci olarak isimiz baska alanlara kaymis durumda, ama artik kod yazmayacagiz.

Artik en önemli görevlerimizden birisi test yazmak / yazdirmak ve yapay zekanin olusturdugu kodun yani olusturmak istedigimiz ürünün davranislarini test etmek. Ama test kodunu da tamamen yapay zekaya birakmak, onun calip, onun oynadigi bizim ise sadece seyredici oldugumuz bir ortam dogurur. Bu da istedigimiz bir durum olamaz. Bizim girdileri ve ciktilari kontrol edebilecegimiz yeni bir soyutluk seviyesine ihtiyacimiz var.

Cogumuz “yapay zekaya testleri de yazdirabiliriz, hem de bunu bizden daha genis kapsamli yapar” diyecektir. Burada bazi problemler görüyorum:

• Kodu degistiren yapay zekanin testleri de adapte etmesi tehlikeli ve bu kontrol edilemez sonuclar dogurabilir (kendi calip, kendisi oynar metaforu)
• Statik test kodu sürekli kirilmaya müsait oldugundan, bakimi cok zordur. Yine burada “bunu yapay zeka halleder” demek uygun degil, cünkü elimizde tutmak istedigimiz bir kontrol mekanizmasina ihtiyacimiz var
• Test etmek istiyoruz lakin kod yazmak, bakimini yapmak ve adapte gibi detaylar ile ugrasiyoruz. Bunun yerine nasil yerine ne sorusunu sormamiz gerekmektedir. Neyi test ediyoruz sorusu test etmek istedigimiz isletme mantigina odaklanmamizi saglayacaktir. Burada imperatif düsünce yerine neyin test edildigini tayin ettigimiz deklaratif düsünce tarzina gecmis oluyoruz.

Ne yapabiliriz?

Artik düsüncelerimizi belli kaliplara sokarak bilgisayar ile calisma zorunlulugumuz ortadan kalkmis durumda. Biz yapay zeka ile kendi dilimizde iletisim kuruyoruz. Ciktilari kontrol etmek icin kullanacagimiz yeni soyutluk seviyesi de bu.

Bir uygulamanin feature olarak tanimladigimiz ve implemente ettigimiz degisik türde davranislari olabilir. Bu davranislarin uygulama tarafindan sergilenebilmesi icin kullanicilar tarafindan tetiklenmeleri gerekir. Tanimli bir input gerekli davranis bicimi uygulandiktan sonra tanimli bir output doguracaktir. Programci olarak bu girdi ve ciktilari kendi dilimizde tanimlayabilir ve yapay zeka ya da test catisi tarafindan uygulamaya karsi kosturulmalarini saglayabiliriz.

Kendimden bir örnek vereyim. Ben testleri artik bir yml dosyasinda su sekilde specler olarak tanimliyorum:

name: 'Clean Start Test'
description: 'When SQLite-Database deleted, then app starts in default setup mode'

tags:
  - clean

setup:
  - 'Delete database'
tests:
  - name: 'App starts with setup screen'
    steps:
      - 'Start the app'
      - 'Wait 2 secs '
      - 'Expect that "Lütfen cihaz türünü seciniz" is visible'

Sonnet’e bu specleri okuyup (parse, analyse), teste dönüstürüp (generation), kosturabilen (execution) ufak capli bir framework yazdirdim.

Bu specler tanimlamis oldugum onay/kabul kriterlerini ihtiva ediyor. Bir nevi BDD (behaviour driven development) yapiyorum, ama onun ismi artik BDD degil, BDC (behaviour driven check). Testleri bu sekilde tanimladiktan sonra, kosturuyorum. Sonnet’in olusturdugu test framework testleri kosturmadan önce spec dosyalarini yapisal analiz yapiyor ve akabinde test kodunu olusturarak, bunlari kosturuyor.

Ben bir flutter uygulamasini test etmek icin bu yöntemi sectim. Bir web uygulamasini bu sekilde tamamen yapay zeka yardimi ile test etmek cok daha kolay. Playwright isminde bir MCP server mevcut. Onun yardimi ile Sonnet gibi bir LLM spec dosyasi icinde bulunan test adimlarini MCP araciligi ile bir web tarayicisina baglanarak kosturabilir.

Kisaca özetleyecek olursak:

• Artik test kodu yazmiyorum ya da bakmini yapmiyorum.
• Testlerim kirilmiyor.
• Uygulamanin davranislarina odaklaniyorum ve neyin test edilmesini gerektigini tayin ediyorum.
• Yapay zekanin sadece kodu adapte etmesine izin veriyorum, test kodunu (specler) degil. Bu sekilde neyin test edilecegi hakimiyeti bende kaliyor.
• Yapay zekadan destek alarak genis kapsamli specler olusturabiliyorum.

Bu speclerin olusturulma adimini da su sekilde otomatize edecegim. Jira bünyesinde yeni bir feature tanimlarken onay/kabul kriterlerinin de tanimlanmasi gerekiyor. Ben bir kodlama ajanina bu feature i implemente etmesini söyledigimde, ajan ilk adim olarak gerekli test spec dosyalarini. olusturacak. Ajan isini tamamladiktan sonra test icin olusturdugu spec dosyalarini derleyerek, kosturuyor olacak. Bir hata ile karsilasmasi durumunda implementasyonun istenen seviyede olmadigini anlayarak, gerekli adaptasyonlari yapmaya baslayacak. Böyle bir döngü ile aslinda hic insan interaksiyonu olmadan bir uygulamayi feature by feature implemente ettirmek mümkün.

Test ekibine hos geldin yapay zeka :)