강의 미리보기

Tüm Testler Yeşil, Özellik Bozuk: AI Ajanları İçin E2E Testler ve Mimari Kurallar

AI ajanıyla çalışırken birim testlerinin kör noktaları: testler geçer, özellik uçtan uca çalışmaz. E2E testler, mimari kuralların çalıştırılabilir kontrole dönüştürülmesi (arch-check) ve linterden E2E'ye doğrulama hiyerarşisi.

izolasyonun kör noktaları E2E testleri çalıştırılabilir mimari kurallar doğrulama hiyerarşisi

이 강의에서 배울 내용

Birim testlerin özelliğin hazır olduğunu yanlış bildirdiği kör noktayı kendi test kapsamınızda tespit edeceksiniz.
En az bir mimari kuralı dokümandaki paragraf yerine çalıştırılabilir bir betik olarak yazacaksınız.
En ucuz kontrolden en maliyetliye kadar uzanan bir doğrulama hiyerarşisi oluşturacaksınız.

강의 시작 부분

Her şey yeşil. Hiçbir şey çalışmıyor.

Üç katman birim testi — hepsi geçti
“Dışa Aktar” düğmesi: yol bozuk, ilerleme donmuş, bellek sızıntısı var
Beş kusur — ve birim testler hiçbirini yakalamadı

Beş hata, hiçbir testin bakmadığı yerlere saklandı — tam olarak oraya. Sahne şu: bir masaüstü uygulaması ve dosya dışa aktarma işlevi. Üç katmanın tamamında — yol ayrıştırmadan yazma modülüne kadar — birim testler yeşil; ajan “hazır” bildiriyor. Uygulamayı kendiniz açıp düğmeye basıyorsunuz. Yol biçimi yanlış: bileşen mutlak yol bekliyordu, göreli yol geldi. İlerleme çubuğu kımıldamıyor. Büyük dosyalarda uygulama bellek yemeye başlıyor ve sonunda çöküyor. Toplam beş kusur — ve hepsi bileşenler arası sınır noktalarında. Hiçbir birim test bunları fark etmedi; çünkü her test, kendi modülünü komşularından tamamen izole hâlde test etti.

Mit: %100 birim test kapsamı ≠ özelliğin çalışması

🤔 Mit / Sık karıştırılan:
“Birim testler yeşil — demek ki özellik hazır”
✅ Aslında:
Birim test, modülü izole hâlde test eder; modüller arası birleşim noktasını değil
📌 Unutmayın: yeşil birim testler yalnızca her parçanın tek başına çalıştığını kanıtlar

Yüzde yüz birim test kapsamı, özelliğin çalıştığı anlamına gelmez — en sık karıştırılan nokta tam da budur. Birim test, tanımı gereği modülü izole hâlde test eder: bağımlılıklar mock'lanmıştır, ortam değiştirilmiştir. İki gerçek bileşenin birleşim noktasında olup bitenler hakkında hiçbir şey söylemez: veri biçimleri uyuşuyor mu, kaynaklar serbest bırakılıyor mu, mantık gerçek ortamda ayakta kalıyor mu. Tam da bu yüzden dosya dışa aktarma örneğinde ajan her şeyin bittiğinden emindi — ve beş ayrı yerde yanıldı; bunların hiçbiri tek bir modülün içinde değil.

Birim testler tesadüfen kör değildir — bilerek böyle tasarlandılar

Bağımlılıkları mock'la, modülü tek başına test et
Hızlı ve isabetli — ama sistematik olarak kör
Körlük, testlerin hatası değil; tasarımı

Bir fabrika montaj hattını düşünün: fren kaliperi kendi test istasyonunda, direksiyon kendi istasyonunda kontrol edilir; her sensör araçtan sökülüp ayrı ayrı test edilir. Her kontrol hızlı ve isabetlidir — hangi parçanın hatalı olduğu hemen anlaşılır. Ama hiçbir istasyon, tüm parçalar tek bir araca takılıp araç yola çıktığında ne olacağını kontrol etmez. Birim test de aynı şekilde çalışır: çevresindeki her şeyi mock'lar ve tek bir modülü saf hâliyle test eder. Bu, hız ve isabetli teşhis sağlar; ama aynı izolasyon, testleri dört kusur sınıfına karşı sistematik olarak körleştirir — o kusurlar modülün içinde değil, modüllerin birleşim noktalarında yaşar; parçaların tek bir sisteme dönüştüğü tam o noktada. Körlük, testlerin hatası değil; tasarımının doğrudan sonucudur.

전체 강의는 구독 후 이용 가능

전체 버전에는 21개의 슬라이드가 더 있습니다.

로그인하고 구독하면 영상, 모든 슬라이드, 노트, 테스트, AI 튜터, 면접을 이용할 수 있습니다.

로그인 또는 회원가입 구독하기

강의 목차

Her şey yeşil. Hiçbir şey çalışmıyor.
Mit: %100 birim test kapsamı ≠ özelliğin çalışması
Birim testler tesadüfen kör değildir — bilerek böyle tasarlandılar
Birim testin asla göremeyeceği dört hata türü
Birim testler, E2E'den kesinlikle daha az hata görür — bu bir metafor değil
E2E yalnızca çıkıştaki bir filtre değildir
E2E'nin ilk çalıştırmadan önce ajanın kodunu değiştirdiği üç yol
Önce mimari sınırlar, sonra E2E
📖 OpenAI gözlemi: ajanlar örüntüleri kopyalar
Bağımlılık okları yalnızca yukarı akar — ve bunu makine denetler
Değişmezleri sağlayın, uygulamayı mikro yönetmeyin
❓ Dur-kontrol: sıra sizde
Mimari kuralı otomatikleştirmenin üç seviyesi
💡 İnceleme: seviye 2 — linter kuralları
💡 İnceleme: seviye 2 — linter kuralları
Seviye 3: CI'da mimari testler
Review'da aynı yorumu ikinci kez mi yazıyorsunuz? Bu, harness'ınızın bug'ıdır
Reviewer şikâyeti otomatik kontrole nasıl dönüşür: 1-3. adımlar
4-6. adımlar: kontrolü sağlamca sabitleyin — ve asıl olanı unutmayın
E2E ne zaman zorunlu, ne zaman onsuz da olur
Ters çevrilmiş doğrulama piramidi
Tuzaklar: alttan üçüncü seviyede verilen 'hazır' kararı
Proje: checkout için E2E ve ödemeler için arch-check.sh
Unit testler detayları kanıtlar; feature'ın bütünüyle hazır olduğunu değil