Trae bir döngüdür. Builder aracı deponuzu okur, dosyaları düzenler, terminalde komutlar çalıştırır ve bir sonraki adımda ne yapacağına karar vermek için çıktıyı okur. Peki neden API testleriniz bu döngüde değil? Bir GUI'nin arkasında Apidog'da dururlar ve birisi tıklamayı hatırladığında çalışırlar. Aracınız onlara asla dokunmaz.
Çözüm tek bir yapılandırma bloğudur. Apidog CLI, Apidog'da oluşturduğunuz test senaryolarını doğrudan bir terminalden çalıştıran bir npm paketi olan apidog-cli'dir. CLI yüklendikten ve Trae'nin varlığını bildiği anda, Builder bir Apidog senaryosunu birim testlerinizi çalıştırdığı gibi çalıştırır: komutu başlatır, çıkış kodunu okur, kırmızıysa kodu düzeltir.
Eğer CLI'yi henüz yüklemediyseniz, önce bunu yapın. Yapay zeka kodlama aracısı ile Apidog CLI nasıl kurulur makalesi, aracının yazarak yaptığı npm kurulumunu, kimlik doğrulamasını ve ilk çalıştırmayı anlatır. Bu makale, apidog --version komutunun bir sayı yazdığını ve Apidog hesabınızın kimliğinin doğrulandığını varsayar.
Konu Hangi Trae
Trae, ByteDance'ın VS Code üzerine inşa edilmiş, Builder adı verilen bir aracı moduyla dosyaları düzenleyen ve kendi başına terminal komutları çalıştıran bir yapay zeka IDE'sidir. Ürün detaylarını Trae'nin resmi sitesinde okuyabilirsiniz. Bu makale, GitHub'daki bağımsız trae-agent araştırma projesi hakkında değil, masaüstü IDE hakkındadır. Trae'yi açtığınızda düzenleyicinizin yanında bir sohbet paneli görüyorsanız ve aracıyı Builder'a geçirebiliyorsanız, doğru yerdesiniz demektir.
Bu ayrım önemlidir çünkü Trae'nin proje kurallarını öğrenmek için kendi yöntemi vardır ve bu mekanizma, bir kerelik "testlerimi çalıştır" komutunu Builder'ın kendi başına başvuracağı bir şeye dönüştürür. Bu mekanizma bir proje kuralları dosyasıdır. Bu iş akışının araçtan bağımsız versiyonunu önce istiyorsanız, Apidog CLI'ın kapsamlı kılavuzu CLI'yi kendi başına ele alır.
Adım 1: Proje kuralları dosyasını ekleyin
Trae, Builder çalışmaya başlamadan önce kural dosyalarını okur. Proje düzeyindeki dosya, Trae'nin kurallar belgelerine göre deponuzun kök dizininde .trae/rules/project_rules.md konumunda bulunur. Aracı bu kuralları başlatma sırasında yükler ve kod üretirken ve düzenlerken onlara başvurur. Tüm projelerinizde geçerli olan kullanıcı düzeyinde bir user_rules.md de vardır; bu iş akışı için depo kökündeki bir proje dosyası yeterlidir.
## Apidog CLI ile API testi
Bir API uç noktasına dokunan kodu değiştirdiğinizde, bunu birim testlerle değil,
Apidog test senaryosunu çalıştırarak doğrulayın.
Komut:
apidog run -t <scenario_id> -e <env_id> -r cli
Kurallar:
- `apidog run`, her onaylama geçtiğinde 0, herhangi bir başarısızlık durumunda sıfır olmayan bir değerle çıkar.
Özet iyi görünse bile, sıfır olmayan bir çıkış kodunu başarısız bir test olarak değerlendirin.
- Bu makine `apidog login` aracılığıyla zaten kimliği doğrulanmıştır. Asla bir
--access-token bayrağı eklemeyin ve bu dosyaya asla bir jeton koymayın.
- Bir bayrak bilinmiyorsa, `apidog run --help` komutunu çalıştırın ve oradaki tam bayrağı kullanın.
CLI'yi sohbette bahsetmek yerine project_rules.md dosyasına yazmanızın nedeni budur. Sohbet paneline yazılan bir senaryo kimliği, oturum sona erdiğinde kaybolur. .trae/rules/project_rules.md dosyasındaki bir senaryo ise artık her ekip üyesi ve her Builder çalıştırması için orada olacaktır. Trae ayrıca alt dizinlerdeki .trae/rules/ klasörlerini de okur, böylece bir monorepo, her hizmetin yanında hizmet başına kurallar tutabilir.
Adım 2: Komutu Apidog'dan alın
Komutu tahmin etmek zorunda değilsiniz. Apidog'da test senaryosunu açın, CI/CD sekmesine gidin ve oluşturulan apidog run satırını kopyalayın. Zaten -t'den sonra gerçek senaryo kimliğine ve -e'den sonra ortam kimliğine sahiptir, bu nedenle kimlikleri elle icat etmek yerine Apidog'un geçerli olduğunu bildiği bir komutu yapıştırırsınız.
Bu tam kimlikleri .trae/rules/project_rules.md dosyasındaki bloğa yapıştırın, <scenario_id> ve <env_id> yer tutucularını değiştirin. Bayrakların tam listesi ve her birinin ne işe yaradığı için apidog run komut referansına bakın.
Adım 3: Builder'ın testi çalıştırmasını sağlayın
Blok yerleştirildikten sonra, Trae'nin aracısını Builder'a geçirin ve deponuzda başlatın. Builder başlatılırken project_rules.md dosyasını yükler, bu yüzden CLI'nin orada olduğunu zaten bilir. API'nizi etkileyen bir değişiklik yapın veya sadece kontrolü çalıştırmasını isteyin:
Apidog test senaryosunu çalıştır ve bana çıkış kodunu söyle.
Builder, kural dosyanızdan apidog run komutunu verir. Trae'nin onay modeli burada önemlidir: aracı bir kabuk komutu çalıştırmak istediğinde, komutu önerir ve bir Çalıştır düğmesi gösterir ve komut, siz tıklayana kadar Trae'nin terminalinde yürütülmez. Çalıştıktan sonra Builder çıktıyı otomatik olarak okur ve analiz eder. Böylece apidog run'ı bir kez onaylarsınız ve aracı sonucu oradan alır.
-r cli raporlayıcısı, adım adım bir sonuç ve bir özeti doğrudan terminalde yazdırır; Builder, her isteği ve onaylamayı gerçekleştiği anda okur. Çalışmanın yürütüldüğünü ve Builder'ın hem özeti hem de çıkış kodunu raporladığını görmek isteyeceksiniz.
Adım 4: Raporu Trae içinde okuyun
Bir çalıştırma kırmızıya döndüğünde, rapor cevabı içerir. -r cli ile Builder, Trae'nin terminalinde okunabilir bir döküm alır: her istek, her onaylama ve hangisinin beklenen ile gerçek değere göre başarısız olduğu. Başarısız onaylama, tam alanı veya durum kodunu belirtir, bu da genellikle Builder'ın düzeltmeyi bulması için yeterlidir.
Tarayıcıda açabileceğiniz veya bir ekip arkadaşınıza verebileceğiniz bir rapor için HTML raporlayıcıyı ekleyin:
apidog run -t <scenario_id> -e <env_id> -r cli,html
html raporlayıcısı, ./apidog-reports dizinine kendi kendine yeten bir dosya yazar. Listede cli'yi tutun, böylece Builder bir sonraki adımına karar vermek için okuduğu satır içi çıktıyı almaya devam eder. JSON ve JUnit formatları gibi CI panolarının ayrıştırdığı her raporlayıcı için Apidog CLI test raporları kılavuzuna bakın.
Trae'nin kendi döngüsü içinde test etmesi
Önemli olan, siz sormayı bıraktığınızda ve Builder, project_rules.md ona söylediği için senaryoyu kendi başına çalıştırdığında ne olduğudur.
Bir ödeme yanıtı oluşturan bir işleyiciyi düzenleyen Builder'ı hayal edin. Döngüsü değişir: kodu düzenler, sonra zafer ilan etmek yerine Apidog senaryonuzu hazırlık ortamına karşı çalıştırır, çıkış kodunu okur ve buna göre hareket eder. Yeşildiyse devam eder. Kırmızıysa raporu açar, hangi onaylamanın başarısız olduğunu okur (durum kodu, eksik alan, yanlış değer), bir düzeltme dener ve yeniden çalıştırır. API testi, Builder'ın birim testlerinizi zaten çalıştırdığı aynı düzenle-test et-düzelt döngüsünün bir parçası haline gelir. Tek bir talimat yazdınız ve Builder komutu zaten çalıştığı şekilde entegre etti.
Bu, herhangi bir aracı iş akışını güvenli hale getiren delege et-sonra doğrula modelidir. Builder komutu çalıştırır ve sonucu okur; siz Apidog'da senaryoları görsel olarak yazmaya devam edersiniz ve aracının çıkış kodlarını dürüstçe okuduğunu kontrol edersiniz. Daha geniş kalıp için, API testi için yapay zeka aracılarının nasıl kullanılacağını ve Apidog yapay zeka test donanımını görün.
Trae'nin gerçekten CLI'yi çalıştırdığını doğrulayın
Aracılar hak etmedikleri başarıları raporlar ve Builder da bir istisna değildir. Sorunları ne sıklıkta yakaladıklarına göre üç kontrol.
Öncelikle, komutun çalışıp çalışmadığını onaylayın. Trae, Builder'ın yürüttüğü komutları ve bunların terminaldeki çıktılarını gösterir. Tam apidog run satırını ve altında bir sonucu arayın. Eğer Builder testleri çalıştırdığını söylüyor ancak komutu görmüyorsanız, hiç yapmadığı bir şeyi özetlemiştir. Tekrar çalıştırmasını ve ham çıktıyı göstermesini isteyin.
İkincisi, çıkış kodunu onaylayın:
O apidog run komutunun çıkış kodu neydi?
apidog run, her onaylama geçtiğinde 0, herhangi bir şey başarısız olduğunda sıfır olmayan bir değerle çıkar. Bu tek davranış, Builder'ın veya bir pipeline'ın çalıştırmayı temiz bir geçit olarak ele almasını sağlar. Builder'ın metni "testler geçti" dediği halde çıkış kodu sıfır değilse, çıkış kodu doğrudur.
Üçüncüsü, gerçek senaryoyu kullandığını onaylayın. Eğer bir çalıştırma "senaryo bulunamadı" hatasıyla başarısız olursa, Builder bir kimlik uydurmuş veya yanlış hatırlamış olabilir. -t ve -e değerlerini project_rules.md dosyasıyla ve Apidog'un CI/CD sekmesinde oluşturduğu komutla tekrar kontrol edin. Kural dosyanızdaki kimlikler gerçeği yansıtır.
İsteğe Bağlı: Apidog MCP sunucusunu bağlayın
project_rules.md dosyasından apidog run çalıştırmak, ihtiyacınız olanın çoğunu karşılar. Bir MCP sunucusu bağlamak bir adım daha ileri gider. Trae ajanları MCP istemcileri olarak hareket eder, böylece Builder bir MCP sunucusunun sunduğu araçları çağırabilir.
Bir sunucu eklemek için Trae'nin ayarlarına gidin, MCP sekmesine geçin ve ya pazardan bir sunucu seçin ya da Manuel Ekle'yi seçerek sunucunun command, args ve env değerlerini içeren bir JSON bloğunu Trae'nin MCP sunucuları ekleme kılavuzuna göre yapıştırın. Apidog MCP sunucusu, API spesifikasyonlarınızı MCP üzerinden açığa çıkarır, böylece Builder kodu yazarken şemanızı okuyabilir, sadece sonradan değil. İş bölümü nettir: CLI testleri çalıştırır ve MCP, ajana spesifikasyonu besler.
Trae yanlış anladığında
Kurulum sırasında birkaç hata sıkça ortaya çıkar.
Kural dosyasını görmezden geliyor. Eğer Builder genel bir komut çalıştırıyorsa veya hiç çalıştırmıyorsa, dosya yüklenmiyor olabilir. Dezonuzun kök dizininde .trae/rules/project_rules.md konumunda olduğundan ve klasörün rules olarak adlandırıldığından, rule değil, emin olun. Oturumu yeniden başlatmak kuralların yeniden okunmasını sağlar.
Yine de bir erişim jetonu iletiyor. Eğer Builder --access-token eklemeye çalışıyorsa, genel örneklerden tahmin yürütüyordur. Makine apidog login aracılığıyla kimlik doğrulandığı için blok zaten bunu yapmamasını söylüyor. Bu satırı pekiştirin ve asla gerçek bir jetonu project_rules.md dosyasına koymayın. CLI'nin etkileşimli kullanımda ve CI'da kimlik bilgilerini nasıl ele aldığını görmek için Apidog CLI kimlik doğrulamasını inceleyin.
Bir bayrak uyduruyor. "Bilinmeyen seçenek" hatası, Builder'ın sürümünüzde olmayan bir bayrağı tahmin ettiği anlamına gelir. Ona apidog run --help komutunu çalıştırmasını söyleyin ve oradan tam bayrağı kopyalayın; bu, yüklü sürümünüz için her zaman doğrudur.
Başarısız bir çalıştırmada başarılı rapor veriyor. En maliyetli olanı ve çıkış kodu kuralının project_rules.md dosyanızda ve doğrulama adımınızda bulunmasının nedeni budur. Özet ve çıkış kodu çeliştiğinde, çıkış kodu kazanır.
Günlük bir ajandan test edilmiş bir döngüye
Kurulum bu kadar. Kurulum kılavuzunu takip ederek apidog-cli'yi bir kez yükleyin, .trae/rules/project_rules.md dosyasına kısa bir Apidog bloğu ekleyin ve Builder API testlerinizi nasıl çalıştıracağını ve kodu düzenlemek için kullandığı aynı döngü içinde sonucu nasıl okuyacağını bilecektir. Bozuk bir uç nokta, Builder hala değişiklik üzerinde çalışırken yakalanır, gönderildikten sonra değil.
Bir GUI'nin arkasındaki bir test, bir insan tıkladığında çalışır; tek satırlık bir komut ise Builder ne zaman isterse çalışır. Siz Apidog'da senaryoları görsel olarak oluşturmaya devam edin ve aracınız bunları siz izlemezken çalıştırsın. Apidog'u indirin, bir senaryo oluşturun, apidog run komutunu .trae/rules/project_rules.md dosyasına bırakın ve Builder'ın bir sonraki değişiklikte bunu almasını izleyin. Aynı senaryoyu bir aracı olmadan çalıştırmaya hazır olduğunuzda, GitHub Actions'ta Apidog CLI, CI için sırları, raporlayıcıları ve çıkış kodu denetimini kapsar.