Neyi test etmeniz gerektiğini ve neleri ele alabileceğinizi belirleyin.
Bir önceki makalede test durumlarıyla ilgili temel bilgiler ve bunların neleri içermesi gerektiği anlatılıyordu. Bu makalede, test senaryolarının oluşturulması teknik bir bakış açısından derinlemesine incelenmiş, her bir teste nelerin dahil edilmesi ve nelerden kaçınılması gerektiği ayrıntılı olarak açıklanmıştır. Esas olarak, eskiden beri sorulan "Neleri test etmeli?" veya "Neleri test etmemeli?" gibi soruların yanıtlarını öğreneceksiniz.
Genel yönergeler ve kalıplar
İster birim, ister entegrasyon, ister uçtan uca test gerçekleştiriyor olun, belirli kalıpların ve noktaların hayati önem taşıdığını unutmayın. Bu ilkeler her iki test türüne de uygulanabilir ve uygulanmalıdır. Bu nedenle, iyi bir başlangıç noktasıdır.
Basit tutun
Sınav yazmak söz konusu olduğunda, unutulmaması gereken en önemli şeylerden biri basit olmaktır. Beynin kapasitesini düşünmek önemlidir. Ana prodüksiyon kodu önemli bir yer kaplayarak fazla karmaşıklık için çok az alan bırakır. Bu özellikle testler için geçerlidir.
Çalışma alanınız daha azsa testlerinizde daha rahat olabilirsiniz. Bu nedenle test basitliğine öncelik vermek çok önemlidir. Aslında, Yoni Goldberg'ün JavaScript testi en iyi uygulamaları, Altın Kural'ın önemini vurgular. Testiniz karmaşık bir matematik formülü değil, asistan gibi olmalıdır. Diğer bir deyişle, testinizin amacını ilk bakışta anlayabilmeniz gerekir.
Karmaşıklıklarından bağımsız olarak tüm test türlerinde basitliği hedeflemelisiniz. Aslında bir test ne kadar karmaşıksa onu basitleştirmek o kadar kritik olur. Bunu başarmanın bir yolu, testlerin mümkün olduğunca basit tutulduğu ve yalnızca gerekli olanın test edildiği düz bir test tasarımıdır. Bu, her testin yalnızca bir test durumu içermesi ve test durumunun tek, belirli bir işlevi veya özelliği test etmeye odaklanması gerektiği anlamına gelir.
Şu bakış açısıyla düşünün: Başarısız bir testi okurken neyin yanlış gittiğini belirlemek kolay olmalıdır. Testlerin basit ve kolay anlaşılır olmasını sağlamak bu yüzden önemlidir. Bu sayede, ortaya çıkan sorunları hızla tespit edebilir ve düzeltebilirsiniz.
Nelerin değeri olduğunu test edin
Düz test tasarımı da odaklanmayı teşvik eder ve testlerinizin anlamlı olmasını sağlar. Unutmayın, yalnızca kapsam sağlamak için testler oluşturmak istemezsiniz. Testlerin her zaman bir amacı olmalıdır.
Uygulama ayrıntılarını test etmeyin
Testlerde sık karşılaşılan sorunlardan biri, testlerin genellikle bileşenlerde veya uçtan uca testlerde seçici kullanımı gibi uygulama ayrıntılarını test etmek için tasarlanmasıdır. Uygulama ayrıntıları, kodunuzu kullananların genellikle kullanmayacakları, görmeyecekleri ve hatta bilmedikleri şeyleri ifade eder. Bu durum testlerde iki önemli soruna yol açabilir: yanlış negatif ve yanlış pozitif.
Test başarısız olduğunda, test edilen kod doğru olsa bile yanlış negatifler ortaya çıkar. Bu durum, uygulama kodunun yeniden düzenlenmesi nedeniyle uygulama ayrıntıları değiştiğinde gerçekleşebilir. Öte yandan, test edilen kod yanlış olsa bile bir test başarılı olduğunda yanlış pozitif sonuçlar verir.
Bu sorunun çözümlerinden biri, sahip olduğunuz farklı kullanıcı türlerini göz önünde bulundurmaktır. Son kullanıcılar ve geliştiriciler yaklaşımları açısından farklılık gösterebilir ve kodla farklı şekilde etkileşim kurabilir. Testleri planlarken kullanıcıların ne göreceğini veya neyle etkileşime gireceğini göz önünde bulundurmak ve testlerin uygulama ayrıntıları yerine bunlara dayalı olmasını sağlamak çok önemlidir.
Örneğin, değiştirilmeye daha az açık olan seçicileri seçmek testleri daha güvenilir hale getirebilir: CSS seçiciler yerine data-attributes. Daha ayrıntılı bilgi için bkz. Kent C. Dodds'un bu konudaki makalesini inceleyebilir veya bizi takip etmeye devam edin. Bu konuyla ilgili bir makale daha sonra yayınlanacaktır.
Alay etme: Kontrolü kaybetmeyin
Modelleme, birim testlerinde ve bazen de entegrasyon testlerinde kullanılan geniş bir kavramdır. Uygulama üzerinde tam kontrol sahibi olan bağımlılıkları simüle etmek için sahte veri veya bileşen oluşturmayı kapsar. Bu, bağımsız test olanağı sağlar.
Testlerinizde örnekler kullanmak, öngörülebilirliği, endişeleri gidermeyi ve performansı iyileştirebilir. İnsanların dahil olmasını gerektiren bir test yapmanız gerekiyorsa (örneğin, pasaport doğrulaması gibi), test provası kullanarak bunu gizlemeniz gerekir. Tüm bu nedenlerle, örnekler göz önünde bulundurulması gereken değerli bir araçtır.
Aynı zamanda, sahtekarlıklar gerçek kullanıcı deneyimleri değil, örnek oldukları için testin doğruluğunu etkileyebilir. Bu nedenle, taslak ve koçan kullanırken dikkatli olmanız gerekir.
Uçtan uca testlerde uygulama yapmalısınız?
Genel olarak hayır. Ancak alay etmek bazen cankurtaran olabilir, bu yüzden her şeyi tümüyle ortadan kaldırmayın.
Şu senaryoyu düşünün: Üçüncü taraf bir ödeme sağlayıcı hizmeti içeren bir özellik için test yazıyorsunuz. Bu kişilerin sağladığı korumalı bir ortamdasınızdır, yani gerçek bir işlem yapılmıyordur. Maalesef korumalı alan çalışmıyor ve bu nedenle testleriniz başarısız oluyor. Bu düzeltmenin ödeme sağlayıcı tarafından yapılması gerekir. Tek yapmanız gereken sorunun sağlayıcı tarafından çözümlenmesini beklemek.
Bu durumda kontrol edemeyeceğiniz hizmetlere olan bağımlılığı azaltmak daha faydalı olabilir. Entegrasyonda veya uçtan uca testlerde, testlerinizin güven düzeyini düşürdüğünden, taklit yöntemi dikkatli bir şekilde kullanmanız önerilir.
Test özellikleri: Yapılması ve yapılmaması gerekenler
Bu durumda, test ne içerir? Test türleri arasında fark var mı? Ana test türlerine göre uyarlanmış bazı özel yönleri daha yakından inceleyelim.
İyi bir ünite testi için gerekenler nelerdir?
İdeal ve etkili bir birim testi şu özelliklere sahip olmalıdır:
- Belirli yönlere odaklanın.
- Bağımsız çalışır.
- Küçük ölçekli senaryoları ele alın.
- Açıklayıcı adlar kullanın.
- Varsa AAA modelini uygulayın.
- Kapsamlı test kapsamı garantisi sunar.
| Yapılması gerekenler ✅ | Şunları Yapmayın ❌ |
|---|---|
| Testleri mümkün olduğunca küçük tutun. Her test durumu için bir şeyi test edin. | Testleri büyük birimlere yazın. |
| Testleri her zaman ayrı tutun ve biriminizin dışındaki ihtiyaçlarınızla dalga geçin. | Diğer bileşenleri veya hizmetleri ekleyin. |
| Testleri bağımsız tutun. | Önceki testleri kullanın veya test verilerini paylaşın. |
| Farklı senaryoları ve yolları ele alın. | Kendinizi mutlu yol veya negatif testlerle sınırlayın. |
| Açıklayıcı test başlıkları kullanın. Böylece testinizin konusunu hemen görebilirsiniz. | Yalnızca işlev adına göre test edin. Sonuç olarak yeterince açıklayıcı değil: testBuildFoo() veya testGetId(). |
| Özellikle bu aşamada, iyi bir kod kapsamı veya daha geniş bir test durumu yelpazesi hedefleyin. | Her sınıftan veritabanı (G/Ç) düzeyine kadar test yapın. |
İyi bir entegrasyon testinin kapsamı nedir?
İdeal bir entegrasyon testi, bazı ölçütleri birim testleriyle de paylaşır. Ancak dikkate almanız gereken birkaç ek nokta var. İyi bir entegrasyon testi şunları sağlamalıdır:
- Bileşenler arasındaki etkileşimleri simüle eder.
- Gerçek dünya senaryolarını ele alın, örnekler veya taslaklar kullanın.
- Performansı göz önünde bulundurun.
| Yapılması gerekenler ✅ | Şunları Yapmayın ❌ |
|---|---|
| Entegrasyon noktalarını test edin: Birbiriyle entegre edildiğinde her birimin sorunsuz şekilde birlikte çalıştığını doğrulayın. | Birim testlerinin amacı budur. Her bir birimi ayrı ayrı test edin. |
| Gerçek senaryoları test edin: Gerçek dünya verilerinden türetilmiş test verilerini kullanın. | Otomatik olarak oluşturulan yinelenen test verilerini veya gerçek kullanım alanlarını yansıtmayan diğer verileri kullanın. |
| Testinizin tamamının kontrolünü elinizde tutmak amacıyla dış bağımlılıklar için örnekler ve taslaklar kullanın. | Üçüncü taraf hizmetlerinde bağımlılıklar (ör. dış hizmetlere yapılan ağ istekleri) oluşturma. |
| Her testten önce ve sonra bir temizlik rutini kullanın. | Testlerinizde temizleyici tedbirler kullanmayı unutun. Aksi takdirde, test izolasyonu düzgün yapılmadığından test başarısızlıkları veya yanlış pozitif sonuçlar ortaya çıkabilir. |
İyi bir uçtan uca test için neler gerekir?
Kapsamlı bir uçtan uca test için:
- Kullanıcı etkileşimlerini tekrarlayın.
- Kritik önemdeki senaryoları kapsamalıdır.
- Birden fazla katmanı kapsar.
- Eşzamansız işlemleri yönetin.
- Sonuçları doğrulayın.
- Performansı hesaba katın.
| Yapılması gerekenler ✅ | Şunları Yapmayın ❌ |
|---|---|
| API odaklı kısayollar kullanın. Daha fazla bilgi edinin. | beforeEach kancası dahil olmak üzere her adım için kullanıcı arayüzü etkileşimleri kullanın. |
| Her testten önce bir temizlik rutini kullanın. Test izolasyonuna, birim ve entegrasyon testlerinde kullandığınızdan daha fazla dikkat edin. Çünkü burada yan etki riski daha yüksektir. | Her testten sonra temizlemeyi unutun. Kalan durumu, verileri veya yan etkileri temizlemezseniz bunlar daha sonra yürütülen diğer testleri etkiler. |
| Uçtan uca testleri sistem testi olarak kabul edin. Bu nedenle, uygulama yığınının tamamını test etmeniz gerekir. | Birim testlerinin amacı budur. Her bir birimi ayrı ayrı test edin. |
| Test esnasında alaya bir giriş yapın veya hiç alay etmeyin. Dış bağımlılıklarla alay etmek istiyorsanız dikkatli düşünün. | Taklitlere büyük ölçüde güvenmek. |
| Örneğin, aynı testte büyük senaryoları aşırı test etmeyerek performansı ve iş yükünü göz önünde bulundurun. | Kısayolları kullanmadan büyük iş akışlarını kapsamak. |