Yeşil bir durum kodu yalan söyler. `POST /orders` uç noktanız `201 Created` döndürür, yanıt gövdesi mükemmel görünür ve testiniz geçer. Ancak satır gerçekten doğru durumla veritabanına ulaştı mı? Envanter sayısı azaldı mı? Yalnızca HTTP yanıtını okuyan bir test, API'nin ne **söylediğini** kontrol eder, sistemin ne **yaptığını** değil. Bu boşluğu kapatmak için veritabanının kendisine bakmanız gerekir.
İşte bu noktada bir test senaryosundaki veritabanı sorguları değerini kanıtlar. Bir istekten önce bilinen bir durum oluşturursunuz, isteği gönderirsiniz, ardından diskteki gerçeği doğrulamak için tabloyu sorgularsınız. Apidog, Veritabanı Bağlantıları ve Veritabanı İşlemi işlemcisi aracılığıyla bunu dahili olarak sunar, böylece HTTP çağrılarınızı yönlendiren aynı senaryoda harici bir komut dosyası olmadan SQL veya NoSQL komutlarını adımlar olarak çalıştırabilirsiniz. Senaryo oluşturmaya yeni başlıyorsanız, Apidog ile test senaryosu nasıl yazılır hakkındaki kılavuz, bu makalenin üzerine inşa ettiği istek düzeyindeki temel bilgileri kapsar. İlişkisel depolama birimlerinin bu verileri nasıl modellediği konusunda bir hatırlatma için MDN'nin sunucu tarafı genel bakışı sağlam bir başlangıçtır.
Bir testte veritabanı işlemleri size ne kazandırır?
Veritabanına hiç dokunmayan bir API testi bir kara kutudur. Yanıta güvenir. Çoğu zaman bu iyidir, ancak ilginç hatalar API'nin döndürdüğü ile kalıcı hale getirdiği arasındaki boşlukta yaşar: asla değişmeyen bir durum alanı, hiçbir yere işaret etmeyen bir yabancı anahtar, kalıcı olarak silen yumuşak bir silme.
Veritabanı adımları, saf bir HTTP testinin yapamayacağı üç şeyi yapmanızı sağlar:
- Bir testin artakalan verilere maruz kalmaması için hassas bir başlangıç durumu **oluşturmak**.
- API'nin yazdığını iddia ettiği satırı okuyarak **temel doğruyu doğrulamak**.
- Veritabanından **gerçek bir değer çıkarmak** ve bir sonraki isteğe beslemek, böylece testiniz sunucunun gerçekten oluşturduğu kimlikleri kullanır, tahminleri değil.
Apidog özelliği ikiye ayırır. İlk olarak, Ayarlar > Veritabanı Bağlantıları altında yeniden kullanılabilir bir bağlantı oluşturursunuz. Ardından, bir Veritabanı İşlemi adımını bir isteğe Ön İşlemci (istek öncesi çalışır) veya Son İşlemci (istek sonrası çalışır) olarak eklersiniz. Projedeki her senaryoda yeniden kullanılan tek bir bağlantı.
Planlamadan önce kapsamla ilgili bir not. MySQL, SQL Server (2014 ve daha yenisi), PostgreSQL ve Oracle ücretsiz planda çalışır. ClickHouse, MongoDB ve Redis ücretlidir. MongoDB belgeleri bunu açıkça belirtir: MongoDB'ye bağlanmak ücretli bir özelliktir. Redis için de aynı. Dolayısıyla aşağıdaki MySQL kılavuzu ücretsiz katmanda çalışır; Mongo ve Redis bölümleri ücretli bir plana ihtiyaç duyar.
Adım 1: Veritabanı bağlantısı oluşturun
Ayarlar > Veritabanı Bağlantıları'nı açın ve sağ üstteki **+ Yeni** düğmesine tıklayın. Veritabanı türünüzü seçin, ardından bağlantı alanlarını doldurun:
- **Host** (örneğin `db.staging.internal` veya `127.0.0.1`)
- **Port** (`3306` MySQL için)
- **Kullanıcı Adı** ve **Şifre**
- **Veritabanı Adı** (örneğin `shop`)
Veritabanınız bir bastion arkasındaysa, **SSH Tüneli** bölümünü genişletin ve atlama ana bilgisayarı ayrıntılarını ekleyin. MySQL ayrıca dört seçenekli bir SSL modunu da sunar: `Prefer` (varsayılan, SSL'i dener ve sonra geri döner), `Require`, `Verify CA` ve `Verify Full`. Sunucunuzun desteklediği en katı olanı seçin. Ardından **Kaydet**'e tıklayın.
İki bağlantı tuhaflığı sizi kafa karıştırıcı bir öğleden sonra geçirmekten kurtarır:
- **MySQL 8 kimlik doğrulaması.** Varsayılan `caching_sha2_password` eklentisi bağlantıyı reddedebilir. Bir kimlik doğrulama hatası alırsanız, `ALTER USER 'tester'@'%' IDENTIFIED WITH mysql_native_password BY '...';` ile kullanıcıyı değiştirin ve tekrar deneyin. MySQL referans kılavuzu eklenti farkını ayrıntılı olarak açıklar.
- **Kimlik bilgileri yereldir.** Bağlantı ayrıntıları kendi makinenizde saklanır ve bulutla senkronize edilmez. Her ekip üyesi bağlantıyı kendisi yapılandırır. Bir ekibi koordine ediyorsanız, veritabanı bağlantı ayarlarını paylaşma ile ilgili notlar iş akışını açıklar.
Adım 2: Bir Ön İşlemci ile veri oluşturun
Sipariş oluşturma akışını test ettiğinizi varsayalım. Bir sipariş vermeden önce bilinen bir müşterinin mevcut olmasını istersiniz, böylece test tabloda ne olursa olsun ona bağlı kalmaz.
İsteğinizi açın, **Ön İşlemciler**'i bulun, **Veritabanı İşlemcisi Ekle** üzerine gelin ve **Veritabanı işlemi**'ni seçin. Adını `seed customer` gibi bir şey koyun, MySQL bağlantınızı seçin, ardından **SQL Komutu Girin** altına bir ekleme yazın. Dinamik değişkenler `{{variable_name}}` sözdizimini kullanır, böylece değerleri doğrudan ortamınızdan çekebilirsiniz:
INSERT INTO customers (id, email, status)
VALUES ({{customer_id}}, '{{customer_email}}', 'active')
ON DUPLICATE KEY UPDATE status = 'active';
Şimdi istek garantili bir duruma karşı çalışır. Müşteri mevcuttur, aktiftir ve sonraki adımlarınızın zaten bildiği bir kimliğe sahiptir. Bir Ön İşlemci'de veri oluşturma, her testi test sırası yan etkilerine dayanmak yerine kendi içinde tutar.
Adım 3: Bir Son İşlemci ile veritabanına karşı doğrulayın
İşin özü burada. İsteğiniz bir sipariş oluşturur. Döndükten sonra, satırın doğru durumla mevcut olduğunu doğrulamak için `orders` tablosunu sorgularsınız.
API'nizi çağıran isteği ekleyin:
POST /api/orders
Content-Type: application/json
{
"customer_id": {{customer_id}},
"items": [{ "sku": "APRON-01", "qty": 2 }]
}
Yanıt gövdesinin yeni sipariş kimliğini taşıdığını varsayalım, bunu normal bir yanıt doğrulamasıyla `order_id` adlı bir değişkene yakalarsınız. Şimdi o istekteki **Son İşlemciler**'i açın. TASARIM Modu'nda bunları **Çalıştır** sekmesinde bulacaksınız; HATA AYIKLAMA Modu'nda ise **İstek** sekmesindedirler. **Son İşlemci Ekle** üzerine gelin, **Veritabanı işlemi**'ni seçin, adını `verify order row` koyun ve bağlantınızı seçin.
**İşlemi Yapılandır** altında, işlemi seçin ve SQL'i girin:
SELECT id, status, total_cents
FROM orders
WHERE id = {{order_id}};
Sorgu sonuçları, her satır için bir tane olmak üzere nesne dizisi olarak geri gelir. Tek bir alanı çıkarmak için **Sonuçları Çıkar (İsteğe Bağlı)**'yı açın ve bir **Sonucu Değişkene Çıkar** girişi ekleyin. `db_order_status` gibi bir **Değişken Adı** ve ilk satırdan alanı izole eden bir **JSONPath İfadesi** ayarlayın:
$[0].status
**Gönder**'e tıklayın ve ham sonucu ve çıkarılan değeri görmek için **Konsol**'u kontrol edin. Artık `db_order_status`, diskte gerçekten ne olduğunu tutar. Eşit olduğundan emin olmak için bir doğrulama ekleyin (`pending` veya API'nizin ayarlaması gereken neyse), ve testiniz sonunda sadece HTTP yankısını değil, kalıcılığı doğrular. API `201` döndürdüyse ancak `status = 'draft'` yazdıysa, bunu yakalayan adım budur.
Adım 4: Bir veritabanı değeri çıkarın ve sonraki akışta kullanın
Çıkarma sadece doğrulamalar için değildir. Genellikle veritabanı, yanıtın asla döndürmediği bir değer tutar ve bir sonraki istek için buna ihtiyacınız vardır.
Bir sipariş oluşturmanın aynı zamanda sunucuda bir dahili `fulfillment_ref` oluşturduğu, satıra yazıldığı ancak API yanıtından çıkarıldığı bir akış düşünün. Bir sonraki isteğiniz olan `GET /api/fulfillments/{ref}` buna ihtiyaç duyar. Bunu bir Son İşlemci'de sorgulayın:
SELECT fulfillment_ref
FROM orders
WHERE id = {{order_id}};
`fulfillment_ref` **Değişken Adı** ve `$[0].fulfillment_ref` **JSONPath İfadesi** ile çıkarın. Apidog bu değişkeni ortama göre kapsadığı için, bir sonraki isteğiniz yolunda veya gövdesinde sadece `{{fulfillment_ref}}`'e başvurur ve gerçek, sunucu tarafından oluşturulan değeri alır. Bu, test adımları arasında veri geçirme ve API test orkestrasyonu ve veri geçirme konularında ele alınan HTTP yanıtlarını zincirleme deseniyle aynıdır, ancak doğruluk kaynağı bir JSON gövdesi yerine bir tablodur.
MongoDB ve Redis: NoSQL varyantları
İşlemci, farklı bir yapılandırma yüzeyiyle NoSQL depolar için aynı şekilde çalışır. Her ikisi de ücretli özelliklerdir, bu yüzden buna göre plan yapın. Apidog belgeleri ihtiyacınız olursa tam alan referansına sahiptir.
MongoDB
Bir Veritabanı İşlemi adımı ekleyin ve tür olarak MongoDB'yi seçin. Ham SQL yerine Find, Insert, Update, Delete ve **Veritabanı Komutu Çalıştır** seçenekleriyle bir **İşlem Türü** açılır menüsü alırsınız. Herhangi bir CRUD eylemi için **Koleksiyon Adı** zorunludur. **Sorgu Koşulu** alanı JSON alır:
{ "_id": "65486728456e79993a150f1c" }
Apidog, eşleşen bir kimlik dizesini otomatik olarak bir ObjectId'ye dönüştürür, böylece kendiniz sarmalamak zorunda kalmazsınız. BSON türlerine ihtiyacınız olduğunda, `ISODate(...)`, `ObjectId(...)`, `NumberDecimal(...)` ve `NumberLong(...)` yardımcıları desteklenir; MongoDB kılavuzu bunların her birinin depolanan bir değere nasıl eşlendiğini belgeler. Bağlantı, tam bir bağlantı dizesini veya ayrı ana bilgisayar ve kimlik bilgisi bileşenlerini kabul eder.
Bir dürüstlük notu: MySQL akışı JSONPath çıkarımını bir değişkene belgeler, ancak MongoDB ve Redis belgeleri aynı **Sonucu Değişkene Çıkar** mekanizmasını açıklamaz. Bu nedenle, Mongo işlemlerine durum oluşturma ve onaylama için güvenin ve Konsol'da doğrulayana kadar SQL tarzı çıkarım yolunun aynı şekilde çalıştığını varsaymayın.
Redis
Redis bağlantısı **Ana Bilgisayar**, **Bağlantı Noktası**, **Şifre** ve **Veritabanı Dizini** ister. Görsel işlemler GET, SET ve DELETE'i destekleyen bir **İşlem Türü** açılır menüsü kullanır. Önbelleğe alınmış bir oturumu okumak için GET'i seçin ve **Anahtar**'ı `user:session:123` gibi bir değere ayarlayın. Açılır menünün kapsamadığı her şey için, **Redis Komutu Çalıştır** sekmesi geçerli herhangi bir komutu çalıştırır:
KEYS user:*
Bu, API'nin yazması beklenen bir önbellek girişini nasıl doğruladığınız veya bir testten önce birini temizleyerek uç noktanın onu yeniden doldurduğunu nasıl kanıtladığınızdır.
Gelişmiş varyasyonlar ve sınırlar
Büyük bir paket oluşturmadan önce bilinmesi gereken birkaç şey:
- **Döngüler.** Bir ForEach adımındaki satırlar üzerinde yinelendiğinizde, mevcut döngü öğesine `{{$.StepID.element.field}}` ile başvurun, burada `StepID` döngü adımının gerçek numarasıdır. Her yinelemede bir satır doğrulamak için kullanışlıdır.
- **DB değerine göre dallanma.** Bir durum alanı çıkarın, ardından senaryonun geri kalanını ona göre yönlendirin. Veritabanı okumalarını API test senaryolarında koşullu mantık ile eşleştirmek, bir satır `paid` olduğunda bir yol, `pending` olduğunda başka bir yol izlemesini sağlar.
- **Ortam yönlendirmesi.** Bu aşağıda daha fazla açıklanacak, ancak kısa versiyonu: her ortam için bir bağlantı tanımlayın ve Apidog doğru olanı otomatik olarak seçer.
- **Saklı prosedürler.** Görsel arayüz, saklı prosedürler gibi karmaşık işlemleri yönetmez. Adımlarınızdaki SQL'i basit ifadelere saklayın.
- **Oracle kurulumu.** Oracle, bağlanmadan önce makinenize ayrı bir Oracle İstemcisi kurulmasını gerektirir.
Ortama göre kimlik bilgilerini yönetin
Bir testin yanlışlıkla üretim verilerine çarpmasını asla istemezsiniz. Apidog'un cevabı, her ortam için bir Veritabanı Bağlantısı'dır. Her biri kendi ana bilgisayarı ve parolasına sahip bir `staging` bağlantısı ve bir `local` bağlantısı oluşturursunuz.
Ardından, sağ üst köşedeki açılır menüyü kullanarak ortamları değiştirirsiniz. Apidog, senaryodaki her sorguyu otomatik olarak şu anda seçilen ortama uyan bağlantıya yönlendirir. `staging`'i seçtiğinizde `SELECT`'iniz staging'e karşı çalışır; `local`'a geçiş yaptığınızda tam olarak aynı adım, SQL veya adımda herhangi bir düzenleme yapmadan dizüstü bilgisayarınızın veritabanına karşı çalışır. Kimlik bilgileri, çalışma sırasında herhangi bir manuel yeniden yapılandırma olmadan ortama göre farklılık gösterir.
Bu kimlik bilgileri yerel olarak yaşadığı ve senkronize edilmediği için, bu aynı zamanda üretim parolalarını paylaşılan bulut projesinden uzak tutar. Her mühendis kendi parolalarını tutar.
Apidog CLI ile iş akışını otomatikleştirin
Senaryo uygulamada başarılı olduktan sonra, CI'da başsız olarak çalıştırın, böylece her çekme isteği sadece HTTP sözleşmesini değil, veritabanını da yeniden doğrular. CLI'yi kurun ve kimlik doğrulaması yapın:
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Ardından, oluşturduğunuz senaryoyu, kimliğiyle, seçilen bir ortama karşı çalıştırın:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <senaryo_kimliği> -e <ortam_kimliği> -r cli
Burada `-t` test senaryosu kimliği, `-e` ortam kimliği ve `-r` ise raporlayıcıdır (`cli`, `html` veya `junit`; birkaç tane için virgülle ayırın, örneğin `-r html,cli`). Planlanması gereken bir şey: veritabanı bağlantı ayrıntıları yereldir, bu nedenle çalıştırıcının CI'dan veritabanınıza ulaşmak için dışa aktarılan yapılandırmaya ihtiyacı vardır. Senaryo satırlarını bir veri kümesinden beslerseniz, Apidog CLI ile veri odaklı test her satırın aynı veritabanı doğrulamalarını nasıl çalıştırdığını gösterir ve Apidog ile API testlerini planlama, başarısız bir veritabanı doğrulamasının diğer testler gibi yüzeye çıkması için bunu bir ritimle çalıştırmayı kapsar.
Sıkça Sorulan Sorular
Hangi veritabanları ücretsiz ve hangileri ücretli? MySQL, SQL Server (2014 ve daha yenisi), PostgreSQL ve Oracle ücretsiz plandadır. ClickHouse, MongoDB ve Redis ücretli bir plana ihtiyaç duyar. Hem MongoDB hem de Redis belgeleri bağlantılarının ücretli bir özellik olduğunu belirtir, bu nedenle bir NoSQL paketi planlamadan önce fiyatlandırma sayfasını kontrol edin. Önce ücretsiz veritabanlarını denemek için Apidog'u indirin.
Bir veritabanındaki değeri daha sonraki bir istekte kullanabilir miyim? Evet. Bir Veritabanı işlemiyle bir Son İşlemci ekleyin, bir `SELECT` çalıştırın, ardından bir Değişken Adı ve ilk satırdan alanı izole etmek için `$[0].fulfillment_ref` gibi bir JSONPath İfadesi ile Sonucu Değişkene Çıkar'ı kullanın. Daha sonra `{{variable_name}}` olarak başvurun. HTTP yanıtları için aynı zincirleme fikri, test adımları arasında veri geçirme konusunda ele alınmıştır.
Ekip arkadaşlarım veritabanı bağlantılarımı otomatik olarak alır mı? Hayır. Bağlantı kimlik bilgileri her istemcide yerel olarak depolanır ve bulutla senkronize edilmez, bu nedenle her ekip üyesi bağlantıyı kendisi yapılandırır. Bu kasıtlıdır: üretim parolalarını paylaşılan projeden uzak tutar.
MySQL 8 bağlantım sürekli başarısız oluyor. Neden? MySQL 8, varsayılan olarak bağlantıyı engelleyebilecek `caching_sha2_password` kimlik doğrulama eklentisini kullanır. `ALTER USER ... IDENTIFIED WITH mysql_native_password` ile kullanıcıyı `mysql_native_password`'e geçirin ve yeniden bağlanın.
Saklı prosedürler veya karmaşık veritabanı mantığı çalıştırabilir miyim? Görsel arayüz aracılığıyla hayır. Standart SELECT, INSERT, UPDATE ve DELETE ifadelerini işler, ancak saklı prosedürler gibi karmaşık işlemler desteklenmez. Test adımlarınızı doğrudan ifadelere saklayın.
Özet
Veritabanı sorguları, bir API testini "yanıt doğru görünüyordu"dan "veri gerçekten doğru"ya dönüştürür. Bir Ön İşlemci'de bilinen bir durum oluşturun, bir Son İşlemci'de kalıcı satırı doğrulayın ve sunucu tarafından oluşturulan değerleri bir sonraki isteğe zincirlemek için çıkarın, hepsi aynı senaryo içinde. Her ortam için bir bağlantı kurun ve aynı adımlar düzenleme yapmadan staging veya yerel olarak güvenli bir şekilde çalışır.
Ücretsiz deneyin, kredi kartı gerekmez: Apidog'u indirin, bir MySQL bağlantısını geliştirme veritabanınıza yönlendirin ve bir sonraki isteğinizin oluşturduğu satırı geri okuyan bir Son İşlemci ekleyin.