Cevap.

Konunun geçmişi:

WebSocket üzerinden iletişim, web uygulamalarında (sohbetler, bildirimler, canlı istatistikler) gerçek zamanlı fonksiyonların uygulanması için kullanılır. Zamanla, dinamik web UI'ların artmasıyla web-socket bağlantılarının ve mesajların otomatik test edilmesine olan ihtiyaç doğmuştur. Daha önce bunun için manuel veya düşük seviyeli scriptler kullanılıyordu, şimdi daha özel araçlar (örneğin, test çerçeveleri için WebSocket istemcileri) ortaya çıkmıştır.

Sorun:

Ana zorluk, web-socket'in gerçek zamanlı sunucu durumuna bağlı olması, çift yönlü veri akışının olması, mesajların gönderilmesi/alınmasının senkronize edilmesinin ve doğruluğunun doğrulanmasının daha zor olmasıdır. Ayrıca, bağlantı kopmalarının, yeniden bağlantının, gecikmelerin, teslimat sırasının işlenmesi ve rekabet eden bağlantılar durumunda düzgün çalışmanın test edilmesi gerekmektedir.

Çözüm:

Özel kütüphaneler (örneğin, Node.js için ws, Python'da WebSocket API) kullanarak ve bunları otomatik test pipeline'ına entegre ederek.
Handshake aşamalarını, mesaj değişimini, hata işleme ve yeniden bağlantıyı kontrol eden senaryolar inşa ederek.
Sadece ön yüzü değil, aynı zamanda "uygunsuz" sunucu davranış senaryolarını test etmek için sahte sunucular (veya emülatörler) kullanarak.
Gecikmeler, teslimat sırası ve yeniden bağlantıya dayanıklılık gibi ek kontrol noktaları dahil ederek.

Ana özellikler:

Asenkron mesajlaşma ve iki yönlü trafik ile çalışma.
Testler, gecikme ve kararsız ağ sorunlarına karşı daha duyarlı olabilir (özellikle genel CI'da).
Ekstra günlüğe alma gerekliliği (örneğin, hata ayıklama için JSON değişim günlüğü).

Kandırmaca soruları.

Bir başarılı bağlantı yeterli midir, web-socket sunucusunun çalıştığını kabul etmek için?

Hayır, sadece bağlantının başlatılmasını değil, aynı zamanda doğru yazışmaları, hatalı/eksik mesajların işlenmesini ve olağan dışı kopmaların işlenmesini de test etmek gerekir.

HTTP test araçları WebSocket API'sini kontrol etmek için kullanılabilir mi?

Hayır, aşamalı el sıkışma kısmen HTTP ile uygulansa da, ana değişim farklı bir protokol üzerinden gerçekleşir, dolayısıyla tam bir kontrol için özel araçlar gerekecektir.

Eğer test "yerel" geçiyorsa, CI sunucusunda da her şey çalışacak mı?

Hayır, asenkronluk, ağ gecikmeleri ve artefaktlar genellikle yalnızca CI ortamında ortaya çıkar. Her zaman ortamlar arasındaki farklılığı göz önünde bulundurmak gerekir.

Tipik hatalar ve anti-desain kalıpları

Kopmadan sonra yeniden bağlantı sağlama işleminin göz ardı edilmesi.
Rekabet eden bağlantılar için yeterli testlerin olmaması.
Asenkronluktan dolayı mesajlaşma sonrası durumu yeterince kaydetmeme.

Gerçek hayattan bir örnek

Olumsuz durum

Bir mühendis, web-socket testlerini otomatikleştirmiş: el sıkışma ve 1 mesaj gönderimi için bir kontrol. Test geçiriyor, ancak bir gün bir hata çıkıyor: yeniden bağlantıdan sonra uygulama olayları almaya başlıyor. Testler bunu yakalamadı.

Artılar:

Temel testlerin hızlı uygulanması.
Yeni fonksiyonların uygulanma süresinin kısalması.

Eksiler:

Etkileşimin ve bağlantı dayanıklılığının gerçek kontrolü yok.
Olağan dışı durumlarla ilgili hatalar yakalanmıyor.

Olumlu durum

Testler senaryolar olarak yapılandırılmıştır: el sıkışma, 10 farklı mesajın değişimi (doğru/bozuk), gecikme, zorla kopma, otomatik yeniden bağlantı, yeniden oturum ve rekabetin işlenmesi. Tüm aşamalar günlüklenir ve mesaj ID'lerine göre doğrulanır.