API testlerini Kong’un Insomnia CLI'ı olan inso üzerinden çalıştırıyorsanız ve bir değişiklik düşünüyorsanız, bu rehber size baştan sona yol gösterecektir. Özelliklerinizi ve test paketlerinizi Insomnia'dan nasıl dışa aktaracağınızı, bunları Apidog'a nasıl getireceğinizi ve inso run komutlarınızı apidog run komutları olarak nasıl yeniden yazacağınızı göreceksiniz. Mevcut CI betiklerinizi satır satır eşleştirebilmeniz için bir önce/sonra komut tablosu bulunmaktadır.
Ekipler neden inso'dan Apidog CLI'ya geçiş yapıyor?
inso sağlam bir araçtır. İstek yürütme, Spectral linting ve birim testlerini terminale taşır ve Insomnia’nın Git Sync tarafından oluşturulan bir .insomnia dizininden okur. Eğer bu iş akışı size uyuyorsa, ayrılmanızı gerektirecek bir kural yoktur.
Sürtüşme genellikle CLI'dan değil, Insomnia uygulamasından kaynaklanır. Çoğu geçiş arayışını iki şey tetikler:
- Gerekli bulut hesabı. 2023'te yayınlanan Insomnia 8, birçok ekibi hazırlıksız yakalayan zorunlu bir giriş/bulut hesabı getirdi. Birçok geliştirici yerel öncelikli bir istemci isterken, bunun yerine bir oturum açma duvarıyla karşılaştı.
- Veri kaybı ve geçiş sancısı. Bazı kullanıcılar bu geçiş sırasında veri kaybı ve geçiş olayları yaşadı. Eğer böyle bir durumu tecrübe ettiyseniz, maliyetini zaten biliyorsunuzdur. Şu anda böyle bir durumdan kurtuluyorsanız, şu rehberler size yardımcı olacaktır: Insomnia verilerini kurtarma ve dışa aktarma ve daha derinlemesine Insomnia 8 veri kaybı kurtarma ve geçiş rehberi.
Diğer bir neden ise konsolidasyondur. inso ile CLI, bir yığının yalnızca bir parçasıdır: İstekler için Insomnia, linting için Spectral, mock'lar ve dokümanlar için ayrı araçlar. Apidog ise tasarım, hata ayıklama, test, mock ve dokümantasyonu tek bir platformda birleştirir ve CLI bu platformun test tarafını çalıştırır. Daha az hareketli parça, tek bir doğruluk kaynağı.
Taahhütte bulunmadan önce daha geniş bir bağlam isterseniz, Apidog vs Insomnia ve Insomnia ve Apidog arasında seçim yapma makaleleri, CLl'ler için değil, tam uygulamalar için avantaj ve dezavantajları ortaya koyar.
Başlamadan önce: Neler taşınır, neler taşınmaz
Geçişin ortasında hiçbir şeyin sizi şaşırtmaması için beklentileri baştan belirleyin.
| Insomnia'daki Varlık | Apidog'a Taşınır mı? | Nasıl |
|---|---|---|
| OpenAPI / tasarım belgeleri | Evet | YAML/JSON olarak dışa aktar, Apidog'a içe aktar |
| İstek koleksiyonları | Evet | Dışa aktar, sonra içe aktar |
| Ortamlar ve değişkenler | Evet | Apidog ortamları olarak yeniden oluşturulur |
Birim test paketleri (inso run test) |
Kısmen | Apidog test senaryoları olarak yeniden oluştur |
Spectral lint yapılandırması (inso lint spec) |
Birebir değil | Aşağıdaki dürüst nota bakın |
Dürüst not: inso lint spec, Stoplight'ın OpenAPI linter'ı olan Spectral'ı çalıştırır ve bu gerçek bir güçtür. Apidog CLI bağımsız bir özellik linter'ı, stil rehberi, bölme, birleştirme veya paketleme komutu içermez. Apidog, özelliklerinizi içe aktardığınızda doğrular, bu nedenle yapısal sorunlar içe aktarma sırasında ortaya çıkar; ancak işlem hattınız özel Spectral kural kümelerine bir geçit olarak bağlıysa, Spectral'ı CI'nızda Apidog ile birlikte tutun. apidog lint beklemeyin. Orada değil ve aksi gibi davranmak sizi daha sonra yakacaktır.
Adım 1: Özelliklerinizi ve testlerinizi Insomnia'dan dışa aktarın
inso, tasarım belgenizi doğrudan bir dosyaya yazabilir. Özellik, Insomnia uygulamasında gördüğünüz aynı adla referans alınır:
# Export an OpenAPI design document to a YAML file
inso export spec "My API Design" --output my-api.yaml
Eğer inso verilerinizi bulamazsa, doğru kaynağı işaret edin. Varsayılan olarak, çalışma dizinindeki veya Insomnia uygulamasının veri dizinindeki bir .insomnia dizininden okur. --workingDir veya --src ile geçersiz kılın:
inso export spec "My API Design" --workingDir ./design --output my-api.yaml
İstek koleksiyonları ve inso'nun düzgün bir şekilde dışa aktaramayacağı diğer her şey için Insomnia uygulamasının kendisini kullanın: uygulamayı açın, çalışma alanınızı seçin ve bir OpenAPI veya Insomnia v4 dosyası oluşturmak için Dışa Aktar'ı kullanın. Hem tasarım belgesini hem de koleksiyon dışa aktarımını saklayın. Bunları ayrı ayrı içe aktaracaksınız.
Kurtarma aşamasındaysanız ve uygulama işbirliği yapmıyorsa, dışa aktarma ve kurtarma rehberi, Git Sync veya bulut hesabı size sorun çıkardığında verileri nasıl çıkaracağınızı kapsar.
Adım 2: Apidog'a aktarın
Apidog'u açın, bir proje oluşturun ve az önce dışa aktardığınız YAML veya JSON dosyasını içe aktarın. Apidog, OpenAPI'yi doğal olarak okur, böylece uç noktalarınız, şemalarınız ve örnek verileriniz düzenleyebileceğiniz, mock edebileceğiniz ve test edebileceğiniz yapılandırılmış kaynaklar olarak gelir.
Ayrıca, otomatik bir kurulumun parçası olarak CLI'dan da içe aktarabilirsiniz; bu, UI'da tıklamak yerine ekip çapında bir geçişi betiklediğinizde kullanışlıdır. Apidog, OpenAPI'yi içe aktarır ve uç noktaları, şemaları, ortamları, dalları ve birleştirme isteklerini terminalden kod olarak yönetir, oturum açma veya erişim belirteci aracılığıyla kimlik doğrulaması yapar. CLI'yi ilk kez kuruyorsanız, Apidog CLI kurulum rehberi ve eksiksiz CLI rehberi kurulumu ve kimlik doğrulama akışını kapsar.
İçe aktarma sırasında Apidog, özelliği doğrular. OpenAPI'nizde yapısal sorunlar varsa, bunu çalışma zamanında değil, şimdi öğrenirsiniz. Bu, inso lint spec'e en yakın karşılıktır, ancak tekrarlamaya değer bir farkla: bu bir doğrulamadır, yapılandırılabilir bir Spectral kural kümesi değil.
Adım 3: Komutlarınızı eşleştirin (geldiğiniz bölüm)
Bu, geçişin özüdür. İşte inso komutlarının apidog run'a nasıl çevrildiği.
| Ne yapmak istiyorsunuz | inso komutu | Apidog CLI karşılığı |
|---|---|---|
| Birim test paketi çalıştır | inso run test "Smoke Suite" --env "Staging" |
apidog run --test-scenario "Smoke Suite" -e staging |
| Koleksiyon çalıştır | inso run collection "Checkout Flow" --env "Staging" |
apidog run "Checkout Flow" -e staging |
| Adlandırılmış betik çalıştır | inso script ci-smoke --env <env-id> |
apidog run -e <env-id> (CI betiğinize entegre) |
| OpenAPI özelliğini lint et | inso lint spec "My API Design" |
Birebir karşılığı yok; Apidog içe aktarma sırasında doğrular |
| Bir özelliği dosyaya aktar | inso export spec "My API Design" --output api.yaml |
Apidog içe/dışa aktarımı tarafından işlenir, çalışma zamanı adımı değil |
Eşleştirme hakkında birkaç not:
- Ortamlar.
inso--env "isim"kullanır. Apidog-e(--env) kullanır. Her ikisi de hangi ortamın temel URL'sini ve değişkenlerini uygulayacağını seçer. Önce Insomnia ortamlarınızı Apidog ortamları olarak yeniden oluşturun, ardından bunlara ad veya kimlik ile başvurun. - Test paketleri test senaryoları olur.
inso run testbir Insomnia birim test paketini çalıştırırken, Apidog test senaryolarını çalıştırır. Konsept net bir şekilde eşleşir: iddialarla sıralanmış istekler. Paketi Apidog'da bir kez yeniden oluşturursunuz, ardından herapidog runkomutunda çalışır. inso scriptdolaylı bir yöntemdi. Komutları adlandırılmış betiklerin arkasına sarmaladıysanız, doğrudan CI adımınızdaapidog runçağırın veya kendi npm/make betiğinize sarın.
Daha derinlemesine bir komut komut karşılaştırması için, Apidog CLI vs inso (Insomnia CLI) her bir bayrağı detaylıca inceler. Geçmişte Newman veya Postman CLI kullandıysanız, Apidog CLI vs Newman ve Apidog CLI vs Postman CLI de bu konuları kapsar.
Adım 4: Raporlayıcılarınızı taşıyın
inso, CI için test çıktısı ve JUnit tarzı raporlamaya dayanır. Apidog size CLI, HTML ve JSON formatlarında raporlayıcılar sunar, böylece derlemeniz hem konsola insan tarafından okunabilir sonuçlar yazdırabilir hem de aynı anda makine tarafından okunabilir bir çıktı üretebilir:
# Run a scenario and emit both a CLI summary and an HTML report
apidog run --test-scenario "Smoke Suite" -e staging -r cli,html
Aşağı akış bir araç sonuçları ayrıştırmak gerektiğinde json'ı, bir insan derlemeyi incelediğinde html'i ve canlı konsol akışı için cli'yi seçin. Ayrıca --upload-report ile sonuçları Apidog'un bulut test raporlarına da gönderebilirsiniz, böylece tüm ekip CI günlüklerini karıştırmadan çalıştırmayı görebilir. Test raporları rehberi formatları ayrıntılı olarak kapsar.
Adım 5: Veri odaklı testleri taşıyın
Eğer Insomnia paketleriniz veriler üzerinde döngü yapıyorsa, Apidog veri odaklı testleri doğal olarak destekler. -d ile bir CSV veya JSON veri kümesi besleyin ve senaryo her satır için bir kez çalışır:
apidog run --test-scenario "Login Matrix" -e staging -d ./users.csv -r cli,json
Bu, Apidog'un inso aracılığıyla harici verileri zincirlemekten daha az zorlama hissettirdiği bir noktadır. Veri odaklı test rehberi, veri kümesi formatları ve değişken bağlamayı anlatır.
Adım 6: CI'ya entegre edin
Son adım, işlem hattınızdaki komutu değiştirmektir. Eski GitHub Actions veya GitLab adımınız muhtemelen şöyle görünüyordu:
# Önce: CI'da inso
inso run test "Smoke Suite" --env "CI" --reporter junit
Apidog eşdeğeri:
# Sonra: CI'da Apidog CLI
apidog run --test-scenario "Smoke Suite" -e ci -r cli,json --upload-report
Çalıştırıcıyı, herhangi bir kimlik bilgisi adımıyla yaptığınız gibi, bir CI sırrı olarak saklanan bir erişim belirteciyle kimlik doğrulayın. CI/CD işlem hattı rehberi ve GitHub Actions rehberi kopyala-yapıştır iş akışı dosyalarına sahiptir. Belirteç ve oturum açma ayrıntıları için Apidog CLI kimlik doğrulamasına bakın.
Eğer linting için Spectral'ı koruduysanız (özel kurallarınız varsa önerilir), işlem hattınızda artık iki geçit var: Spectral özelliği lint eder, Apidog testleri çalıştırır. Bu tamamen makul bir son durumdur ve her aracın en iyi ne yaptığını dürüstçe ortaya koyar.
Spectral'ı döngüde tutmak
Aktarılmayan tek şey hakkında net olmak gerekirse: eğer linting sözleşmenizin bir parçasıysa, onu bırakmayın. Spectral açık kaynaklıdır ve Insomnia dışında sorunsuz çalışır. Tipik bir hibrit CI şöyle görünür:
# Spectral ile Lint et (inso kurulumunuzdan korunmuş)
npx @stoplight/spectral-cli lint my-api.yaml
# Apidog CLI ile test et
apidog run --test-scenario "Smoke Suite" -e ci -r cli,json
Linting tarafında hiçbir şey kaybetmezsiniz ve diğer her şeyde Apidog'un entegre tasarım-mock-test-doküman platformunu kazanırsınız. Bu doğru bir takastır ve çoğu ekip için iyi bir seçenektir.
Bir Bakışta inso ve Apidog CLI Karşılaştırması
| Yetkinlik | inso (Insomnia CLI) | Apidog CLI |
|---|---|---|
| Koleksiyonları / paketleri çalıştır | Evet | Evet |
| Ortamlar | --env |
-e / --env |
| OpenAPI linting | Evet (Spectral) | Bağımsız komut yok (içe aktarma sırasında doğrular) |
| Veri odaklı test | Sınırlı | Evet (-d, CSV/JSON) |
| Rapor formatları | CLI, JUnit | CLI, HTML, JSON, buluta yükleme |
| Kod olarak kaynak | .insomnia dizinini okur |
Uç noktalar, şemalar, dallar, birleştirme istekleri |
| Birleşik bir platformun parçası | Insomnia + harici araçlar | Tek platform (tasarım, mock, dokümanlar, test) |
| Uygulama için bulut hesabı gerekli | Evet (Insomnia 8+) | Apidog hesabı, yerel uyumlu |
SSS
Insomnia OpenAPI spesifikasyonum Apidog'a düzenleme yapmadan içe aktarılır mı? Genellikle evet. Apidog, OpenAPI'yi doğal olarak okur ve içe aktarma sırasında doğrular. Eğer doğrulama bir şeyi işaret ederse, bu genellikle spesifikasyonda gerçek bir yapısal sorundur ve bunu bir kez düzeltmek, aşağı akıştaki her araca fayda sağlar.
Apidog CLI'da inso lint spec gibi bir lint komutu var mı? Hayır. Apidog, spesifikasyonları içe aktarma sırasında doğrular, ancak bağımsız bir CLI linter veya stil rehberi komutu yoktur. Özel Spectral kural kümelerine güveniyorsanız, Spectral'ı apidog run yanında işlem hattınızda tutun. Yan yana bir karşılaştırma için, Redocly CLI bir linter içerdiğinden Apidog CLI vs Redocly CLI'ya bakın.
Apidog CLI'yı, inso'yu çalıştırdığım gibi CI'da çalıştırabilir miyim? Evet. Komutu değiştirin, bir CI sırrından alınan bir erişim belirteciyle kimlik doğrulayın ve raporlayıcılarınızı seçin. CI/CD rehberi tam iş akışı örnekleri içerir.
Insomnia birim test paketlerime ne olur? Bunları Apidog test senaryoları olarak yeniden oluşturursunuz. Yapı doğrudan aktarılır: sıralı istekler artı onaylamalar. Bu tek seferlik bir yeniden oluşturmadır ve sonrasında her apidog run komutunda çalışırlar.
Bir veri kaybı olayı nedeniyle Insomnia'dan geçiş yapıyorum. Nereden başlamalıyım? Öncelikle kurtarma ve dışa aktarma rehberini kullanarak verilerinizi kurtarın, ardından temizlenmiş dışa aktarımı Apidog'a aktarmak için yukarıdaki Adım 2'yi izleyin.
Sonuç
inso'dan Apidog CLI'ya geçiş çoğunlukla bir çeviri işidir: özelliklerinizi ve paketlerinizi dışa aktarın, bunları Apidog'a aktarın, inso run test ve inso run collection komutlarını apidog run olarak yeniden yazın, --env'yi -e'ye çevirin ve raporlayıcılarınızı Apidog'un CLI/HTML/JSON çıktısına yönlendirin. Eğer linting yapıyorsanız Spectral'ı koruyun, çünkü Apidog içe aktarma sırasında doğrulama yapar ancak özel bir kural kümesini değiştirmez.
Kazanç, sürekli bir araya getirmeniz gereken bir yığın yerine tek bir platformdur. Denemeye hazır mısınız? Apidog'u indirin ve az önce dışa aktardığınız özellikle ilk apidog run komutunuzu çalıştırın.
