Cevap.

Doğru versiyonlama ve otomatik testlerin entegrasyonu, testlerin projenin güncel durumu ile uyumlu olmasını sağlamak için kritik öneme sahiptir.

Konu Tarihi

Otomatik testler başlangıçta genellikle ana projeden ayrı kaydediliyordu, bu da uyumsuzluklara ve destek sorunlarına yol açıyordu. Birden fazla branşın gelişimi, sık yazılım ve test sürümleri gereksinimini doğurdu; bu da ortak bir versiyon kontrol sistemi ihtiyacını ortaya çıkardı.

Sorun

Versiyonlama ve uyumlu entegrasyon olmadan şu sorunlar ortaya çıkar:

Değiştirilen yazılım üzerinde güncel olmayan testlerin çalıştırılması
Yeni özelliklerin çıkışında, testlerdeki değişiklikleri dikkate almayan "kırık" testler
CI/CD'de aksaklıklar

Çözüm

Modern yaklaşım:

Testler ortak bir versiyon kontrol sisteminde (genellikle git) saklanır
Test dalının yazılım gelişim dalına bağlanması: feature dalında testler ve kod birlikte gider
Pull request'ler üzerinden otomatik kontroller/toplamalar yapılır
Testler ve kod değişikliklerinin gözden geçirilmesi ve onaylanması

# Genel yaklaşım:
git checkout -b feature/new_login
# Özellik ve testler birlikte geliştirilir ve test edilir
# Gözden geçirildikten sonra ana daldan birlikte birleştirilir

Ana Özellikler:

Kod ve test değişikliklerinin uyumluluğu (senkronizasyon eksikliği yok)
Kolay geri alma ve versiyon karşılaştırması (git geçmişi üzerinden)
Takım işbirliği ve otomatik testlerin kod gözden geçirmesi imkanı

Tuzağa Düşüren Sorular.

Testler projeden ayrı bir depoda saklanabilir mi?

Evet, ancak bu durumda testlerin güncel tutulması daha zor hale gelir, manual senkronizasyon gerektirir, bir sürüm veya hata düzeltmesi sırasında bir şeyi "unutturma" riski vardır.

Yeni bir PR oluşturulduğunda testler hemen yeni işlevselliği kapsamalı mı?

İdeal olarak — evet, ancak pratikte genellikle ilk PR'da MVP/ana senaryolar kapsanır, karmaşık durumlar ayrı görevler şeklinde. Anahtar işlevselliğin hemen kapsanması en önemlisidir.

Sadece test değişikliklerini kodu geri almadan geri alabilir miyiz?

Eğer testler ve kod aynı dalda bulunuyorsa — evet, versiyonları geri alabilirsiniz. Ancak kod olmadan testlerin "geri alınması" kaçınılmalıdır: bu, test kalitesini kötüleştirir.

Tipik Hatalar ve Antipatternler

Testlerin git dışında dosya sistemlerinde saklanması
Net bir proje bağlantısı olmadan ayrı bir repoda testlerin tutulması
Testlerin dışarıdan (post factum) eklenmesi, kodla aynı anda değil

Hayatın İçinden Bir Örnek

Olumsuz Durum

Ayrı bir otomatik test deposu olan bir proje. Sürümden sonra programcılar testleri "unutmuş"; testler başarısız oldu, güncel olmayan kontroller geçti, hatalar canlıda yakalandı.

Artıları:

Programcılar QA'den bağımsız çalışabilirdi

Eksileri:

Senkronizasyon için zaman kaybı, "eski" testlerin varlığı

Olumlu Durum

Testler ve proje kodu aynı git dalında tutulur: her yeni pull request ile birlikte eklenen kod için otomatik testler mutlaka güncellenir. Tüm değişiklikler kod gözden geçirmesinden ve otomatik kontrol süreçlerinden geçer.