Neleri test etmeniz gerektiğini ve neleri eleyeceğinizi belirleyin.
Önceki makalede, test amaçlarının temel özellikleri ve içermeleri gerekenler ele alınmıştı. Bu makalede, test senaryolarının teknik açıdan oluşturulması ele alınmakta, her teste nelerin dahil edilmesi ve nelerden kaçınılması gerektiği ayrıntılı olarak açıklanmaktadır. Temel olarak, "Neleri test etmeliyiz?" veya "Neleri test etmemeliyiz?" gibi eski soruların cevabını öğreneceksiniz.
Genel kurallar ve kalıplar
Birim, entegrasyon veya uçtan uca testler yapıp yapmadığınızdan bağımsız olarak belirli kalıpların ve noktaların çok önemli olduğunu belirtmek isteriz. Bu ilkeler her iki test türüne de uygulanabilir ve uygulanmalıdır. Bu nedenle, başlangıç için iyi bir noktadır.
Basit tutun
Test yazma konusunda dikkat etmeniz gereken en önemli noktalardan biri, testleri basit tutmaktır. Beynin kapasitesini dikkate almak önemlidir. Ana üretim kodu önemli miktarda yer kaplar ve ek karmaşıklığa çok az yer bırakır. Bu durum özellikle test için geçerlidir.
Daha az yer varsa test çalışmalarınızda daha rahat olabilirsiniz. Bu nedenle, testlerde sadeliğe öncelik vermek çok önemlidir. Aslında Yoni Goldberg'in JavaScript testi en iyi uygulamaları, Altın Kural'ın önemini vurgular. Testiniz karmaşık bir matematiksel formül gibi değil, bir asistan gibi hissettirmelidir. Başka 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 basitleştirmek o kadar kritiktir. Buna ulaşmanı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ı kullanmaktır. Bu, her testin yalnızca bir test senaryosu içermesi ve test senaryosunun tek bir belirli işlevi veya özelliği test etmeye odaklanması gerektiği anlamına gelir.
Bu konuyu şu açıdan düşünün: Başarısız bir testi okurken neyin yanlış gittiğini belirlemek kolay olmalıdır. Bu nedenle, testleri basit ve anlaşılır tutmak önemlidir. Bu sayede, ortaya çıkan sorunları hızlı bir şekilde tespit edip çözebilirsiniz.
Değerli olanları test edin
Düz test tasarımı, odaklanmayı da teşvik eder ve testlerinizin anlamlı olmasını sağlar. Testleri yalnızca kapsam için oluşturmak istemediğinizi unutmayın. Testlerin her zaman bir amacı olmalıdır.
Uygulama ayrıntılarını test etmeyin
Testlerde sık karşılaşılan bir sorun, testlerin genellikle bileşenlerde seçici kullanma veya uçtan uca testler gibi uygulama ayrıntılarını test etmek için tasarlanmış olmasıdır. Uygulama ayrıntıları, kodunuzun kullanıcılarının genellikle kullanmayacağı, görmeyeceği veya hatta bilmeyeceği şeyleri ifade eder. Bu durum, testlerde iki önemli soruna yol açabilir: yanlış negatifler ve yanlış pozitifler.
Yanlış negatifler, test edilen kod doğru olsa bile test başarısız olduğunda ortaya çıkar. Bu durum, uygulama kodunun yeniden düzenlenmesi nedeniyle uygulama ayrıntıları değiştiğinde ortaya çıkabilir. Öte yandan, test edilen kod yanlış olsa bile test geçerse yanlış pozitif sonuç elde edilir.
Bu sorunun bir çözümü, 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 neleri göreceğini veya nelerle etkileşime geçeceğini göz önünde bulundurmak ve testleri uygulama ayrıntıları yerine bu öğelere bağlı hale getirmek önemlidir.
Örneğin, değişiklik yapmaya daha az eğilimli seçiciler kullanmak testleri daha güvenilir hale getirebilir: CSS seçicileri yerine veri özellikleri. Daha fazla bilgi için Kent C. Dodds'ın bu konuyla ilgili makalesini inceleyin veya bu konuyla ilgili makalemizi takip edin.
Alay etme: Kontrolü kaybetmeyin
Öykünme, birim testinde ve bazen entegrasyon testinde kullanılan geniş bir kavramdır. Uygulama üzerinde tam kontrole sahip bağımlılıkları simüle etmek için sahte veri veya bileşenler oluşturmayı içerir. Bu sayede, izole test yapabilirsiniz.
Testlerinizde taklitleri kullanmak tahmin edilebilirliği, endişelerin ayrılmasını ve performansı artırabilir. Ayrıca, gerçek bir kullanıcının katılımını gerektiren bir test (ör. pasaport doğrulaması) yapmanız gerekiyorsa bunu bir taklit kullanarak gizlemeniz gerekir. Tüm bu nedenlerden dolayı, provalar dikkate alınması gereken değerli bir araçtır.
Aynı zamanda, gerçek kullanıcı deneyimleri değil de taklitler olduğu için taklitler testin doğruluğunu etkileyebilir. Bu nedenle, taklitleri ve taslakları kullanırken dikkatli olmanız gerekir.
Uçtan uca testlerde taklit oluşturmalı mısınız?
Genel olarak hayır. Ancak bazen alay etmek hayat kurtarıcı olabilir. Bu nedenle, bu seçeneği tamamen göz ardı etmeyelim.
Şu senaryoyu düşünün: Üçüncü taraf ödeme sağlayıcı hizmeti içeren bir özellik için test yazıyorsunuz. Sağlanan korumalı alandasınızdır. Yani gerçek işlemler gerçekleşmez. Maalesef korumalı alan düzgün çalışmadığından testleriniz başarısız oluyor. Düzeltme, ödeme sağlayıcı tarafından yapılmalıdır. Tek yapmanız gereken, sorunun sağlayıcı tarafından çözülmesini beklemektir.
Bu durumda, kontrol edemediğiniz hizmetlere olan bağımlılığı azaltmak daha yararlı olabilir. Yine de, testlerinizin güven düzeyini düşürdüğü için entegrasyon veya uçtan uca testlerde taklit özelliğini dikkatli bir şekilde kullanmanız önerilir.
Test ayrıntıları: Yapılması ve yapılmaması gerekenler
Peki bir testte neler bulunur? Test türleri arasında fark var mı? Ana test türlerine göre uyarlanmış bazı hususları daha yakından inceleyelim.
İyi bir birim testi neleri içerir?
İdeal ve etkili bir birim testi:
- Belirli yönlere odaklanın.
- Bağımsız olarak çalışır.
- Küçük ölçekli senaryoları kapsar.
- Açıklayıcı adlar kullanın.
- Uygun durumlarda AAA kalıbını uygulayın.
- Kapsamlı test kapsamı garantisi.
| ✅ | Yapmayın ❌ |
|---|---|
| Testleri mümkün olduğunca küçük tutun. Her test senaryosu için bir öğeyi test edin. | Büyük birimler üzerinde testler yazın. |
| Testleri her zaman ayrı tutun ve biriminizin dışındaki ihtiyaç duyduğunuz öğeleri taklit edin. | Diğer bileşenleri veya hizmetleri ekleyin. |
| Testleri bağımsız tutun. | Önceki testlerden yararlanın veya test verilerini paylaşın. |
| Farklı senaryoları ve yolları ele alın. | Kendinizi en fazla olumlu yol veya negatif testlerle sınırlandırın. |
| Testinizin neyle ilgili olduğunu hemen görebilmeniz için açıklayıcı test başlıkları kullanın. | Yalnızca işlev adına göre test edildiğinden yeterince açıklayıcı değil: testBuildFoo() veya testGetId(). |
| Özellikle bu aşamada iyi bir kod kapsamı veya daha geniş bir test durumu yelpazesi elde etmeyi hedefleyin. | Her sınıftan veritabanı (G/Ç) düzeyine kadar test edin. |
İyi bir entegrasyon testi neleri kapsar?
İdeal bir entegrasyon testi, birim testleriyle bazı ölçütleri paylaşır. Ancak dikkate almanız gereken birkaç ek nokta vardır. İyi bir entegrasyon testi:
- Bileşenler arasındaki etkileşimleri simüle edin.
- Gerçek yaşam senaryolarını ele alın ve taklitler veya taslaklar kullanın.
- Performansı göz önünde bulundurun.
| ✅ | Yapmayın ❌ |
|---|---|
| Entegrasyon noktalarını test edin: Her bir birimin, diğer birimlerle entegre edildiğinde sorunsuz bir şekilde birlikte çalıştığını doğrulayın. | Her bir birimi ayrı ayrı test edin. Birim testleri bunun içindir. |
| Gerçek dünya senaryolarını test edin: Gerçek dünyadan elde edilen test verilerini kullanın. | Tekrarlanan, otomatik olarak oluşturulmuş test verileri veya gerçek dünyadaki kullanım alanlarını yansıtmayan başka veriler kullanmak |
| Testinizin tamamının kontrolünü elinde tutmak için harici bağımlılıklar için taklitler ve taslaklar kullanın. | Üçüncü taraf hizmetlerine bağımlılıklar oluşturma (ör. harici hizmetlere ağ istekleri gönderme). |
| Her testten önce ve sonra temizleme rutini kullanın. | Testlerinizde temizleme önlemleri kullanmayı unutmayın. Aksi takdirde, uygun test izolasyonu olmadığından test başarısızlıkları veya yanlış pozitif sonuçlarla karşılaşabilirsiniz. |
İyi bir uçtan uca testte neler bulunur?
Kapsamlı bir uçtan uca test:
- Kullanıcı etkileşimlerini kopyalayın.
- Önemli senaryoları kapsamalıdır.
- Birden fazla katmanı kapsayan.
- Eşzamansız işlemleri yönetme
- Sonuçları doğrulayın.
- Performansı hesaba katın.
| ✅ | Yapmayın ❌ |
|---|---|
| API destekli kısayolları kullanın. Daha fazla bilgi edinin. | beforeEach kancası dahil her adımda kullanıcı arayüzü etkileşimlerini kullanın. |
| Her testten önce temizleme rutini kullanın. Yan etki riski daha yüksek olduğundan, birim ve entegrasyon testlerinde olduğundan daha fazla test izolasyonu yapın. | Her testten sonra temizlemeyi unutmayın. Kalan durumu, verileri veya yan etkileri temizlemezseniz bunlar daha sonra çalıştırılan diğer testleri etkiler. |
| Uçtan uca testleri sistem testleri olarak değerlendirin. Bu nedenle, uygulama yığınının tamamını test etmeniz gerekir. | Her bir birimi ayrı ayrı test edin. Birim testleri bunun içindir. |
| Testte taklitleri en aza indirin veya hiç kullanmayın. Harici bağımlılıklara ait taklitleri kullanmak isteyip istemediğinizi dikkatlice düşünün. | Sahte verilere çok fazla güvenme. |
| Örneğin, aynı testte büyük senaryoları aşırı test etmemek gibi performans ve iş yükünü göz önünde bulundurun. | Kısayollar kullanmadan büyük iş akışlarını kapsayın. |