Olumlu Bir Test Deneyimi için 8 Otomatik Test En İyi Uygulaması

Pek çok geliştiricinin test etmeyi zaman ve enerji tüketen gerekli bir kötülük olarak görmesi şaşırtıcı değildir: Test etmek sıkıcı, verimsiz ve tamamen karmaşık olabilir.

İlk test deneyimim çok kötüydü. Sıkı kod kapsamı gereksinimleri olan bir ekipte çalıştım. İş akışı şuydu: bir özelliği uygulamak, hata ayıklamak ve tam kod kapsamı sağlamak için testler yazmak. Ekibin entegrasyon testleri yoktu, yalnızca tonlarca manuel olarak başlatılmış alay içeren birim testleri vardı ve çoğu birim testi, otomatik eşlemeleri gerçekleştirmek için bir kitaplık kullanırken önemsiz manuel eşlemeleri test etti. Her test, mevcut her özelliği doğrulamaya çalıştı, bu nedenle her değişiklik düzinelerce testi kırdı.

Testlerle çalışmaktan hoşlanmadım çünkü zaman alıcı bir yük olarak algılandılar. Ancak pes etmedim. Her küçük değişiklikten sonra sağlanan güven testi ve kontrollerin otomasyonu ilgimi çekti. Okumaya ve uygulamaya başladım ve doğru yapıldığında testlerin hem yararlı hem de eğlenceli olabileceğini öğrendim.

Bu yazıda, keşke en başından beri bilseydim dediğim sekiz otomatik test en iyi uygulamasını paylaşıyorum.

Neden Otomatik Test Stratejisine İhtiyacınız Var?

Otomatik test genellikle geleceğe odaklanır, ancak doğru şekilde uyguladığınızda hemen faydalanırsınız. İşinizi daha iyi yapmanıza yardımcı olan araçları kullanmak zaman kazandırabilir ve işinizi daha keyifli hale getirebilir.

Şirketin ERP'sinden satınalma siparişlerini alan ve bu siparişleri bir satıcıya veren bir sistem geliştirdiğinizi hayal edin. ERP'de daha önce sipariş ettiğiniz ürünlerin fiyatı var ancak mevcut fiyatlar farklı olabilir. Daha düşük veya daha yüksek bir fiyattan sipariş vermeyi kontrol etmek istiyorsunuz. Depolanmış kullanıcı tercihleriniz var ve fiyat dalgalanmalarını yönetmek için kod yazıyorsunuz.

Kodun beklendiği gibi çalışıp çalışmadığını nasıl kontrol edersiniz? Muhtemelen:

1. Geliştiricinin ERP örneğinde sahte bir sipariş oluşturun (önceden ayarladığınızı varsayarak).
2. Uygulamanızı çalıştırın.
3. Bu siparişi seçin ve sipariş verme sürecini başlatın.
4. ERP'nin veritabanından veri toplayın.
5. Satıcının API'sinden mevcut fiyatları isteyin.
6. Belirli koşullar oluşturmak için koddaki fiyatları geçersiz kılın.

Kesme noktasında durdunuz ve bir senaryo için ne olacağını görmek için adım adım gidebilirsiniz, ancak birçok olası senaryo var:

Bir hata durumunda şirket para kaybedebilir, itibarına zarar verebilir veya her ikisini birden yapabilir. Birden fazla senaryoyu kontrol etmeniz ve kontrol döngüsünü birkaç kez tekrarlamanız gerekir. Bunu manuel olarak yapmak sıkıcı olacaktır. Ancak testler yardımcı olmak için burada!

Testler, kararsız API'lere çağrı yapmadan herhangi bir bağlam oluşturmanıza olanak tanır. Eski ERP sistemlerinde çok yaygın olan eski ve yavaş arayüzler üzerinden tekrar tekrar tıklama ihtiyacını ortadan kaldırırlar. Tek yapmanız gereken birim veya alt sistem için bağlamı tanımlamak ve ardından herhangi bir hata ayıklama, sorun giderme veya senaryo araştırması anında gerçekleşir; testi çalıştırırsınız ve kodunuza geri dönersiniz. Tercihim, IDE'mde önceki test çalıştırmamı tekrarlayan ve değişiklik yaptığımda anında, otomatik geri bildirim veren bir tuş bağlama ayarlamaktır.

1. Doğru Tutumu Koruyun

Manuel hata ayıklama ve kendi kendini test etme ile karşılaştırıldığında, otomatik testler, herhangi bir test kodu kaydedilmeden önce bile en başından daha üretkendir. El ile test ederek veya belki daha karmaşık bir modül için, test sırasında bir hata ayıklayıcı ile adım adım ilerleyerek kodunuzun beklendiği gibi davrandığını kontrol ettikten sonra, herhangi bir giriş parametresi kombinasyonu için ne beklediğinizi tanımlamak için onaylamaları kullanabilirsiniz.

Testlerin geçmesiyle, taahhütte bulunmaya neredeyse hazırsınız, ancak tam olarak değil. İlk çalışan sürüm genellikle zarif olmadığı için kodunuzu yeniden düzenlemeye hazırlanın. Bu yeniden düzenlemeyi testler olmadan gerçekleştirir misiniz? Bu şüpheli, çünkü tüm manuel adımları tekrar tamamlamanız gerekecek ve bu da hevesinizi azaltabilir.

Gelecek hakkında ne düşünüyorsun? Testler, herhangi bir yeniden düzenleme, optimizasyon veya özellik ekleme işlemi gerçekleştirirken, bir modülün siz değiştirdikten sonra hala beklendiği gibi davrandığından emin olmanıza yardımcı olur, böylece kalıcı bir güven aşılar ve geliştiricilerin yaklaşan işlerin üstesinden gelmek için daha donanımlı hissetmelerini sağlar.

Testleri bir yük veya yalnızca kod gözden geçirenleri veya kullanıcıları mutlu eden bir şey olarak düşünmek verimsizdir. Testler, geliştiriciler olarak yararlandığımız bir araçtır. Kodumuzun ne zaman çalıştığını seviyoruz ve tekrarlayan eylemlere veya hataları gidermek için kodu düzeltmeye zaman harcamaktan hoşlanmıyoruz.

Son zamanlarda, kod tabanımda yeniden düzenleme üzerinde çalıştım ve IDE'mden using yönergeleri kullanarak temizlemesini istedim. Şaşırtıcı bir şekilde, testler e-posta raporlama sistemimde birkaç hata gösterdi. Ancak bu geçerli bir başarısızlıktı; temizleme işlemi, Razor (HTML + C#) kodumdaki bir e-posta şablonuna ilişkin yönergeleri using yönergelerini kaldırdı ve sonuç olarak şablon motoru geçerli HTML oluşturamadı. Bu kadar küçük bir işlemin e-posta raporlamasını bozacağını beklemiyordum. Testler, yayınlanmadan hemen önce, her şeyin işe yarayacağını varsaydığımda, uygulamanın her yerindeki hataları yakalamak için saatler harcamaktan kaçınmama yardımcı oldu.

Tabii ki, araçları nasıl kullanacağınızı bilmeniz ve atasözü parmaklarınızı kesmemeniz gerekir. Bağlamı tanımlamanın sıkıcı ve uygulamayı çalıştırmaktan daha zor olabileceği, testlerin bayat ve işe yaramaz hale gelmemek için çok fazla bakım gerektirdiği görünebilir. Bunlar geçerli noktalardır ve bunları ele alacağız.

2. Doğru Test Türünü Seçin

Geliştiriciler, yalnızca kod tarafından çağrıldıklarını kontrol etmek için bir düzine bağımlılıkla alay etmeye çalıştıkları için genellikle otomatik testlerden hoşlanmamaya başlarlar. Alternatif olarak, geliştiriciler üst düzey bir testle karşılaşırlar ve küçük bir modüldeki tüm varyasyonları kontrol etmek için her uygulama durumunu yeniden oluşturmaya çalışırlar. Bu modeller verimsiz ve can sıkıcıdır, ancak amaçlandığı gibi farklı test türlerinden yararlanarak bunlardan kaçınabiliriz. (Sonuçta testler pratik ve eğlenceli olmalı!)

Okuyucuların birim testlerinin ne olduğunu ve nasıl yazılacağını bilmeleri ve entegrasyon testlerine aşina olmaları gerekir - değilse, hızlanmak için burada duraklamaya değer.

Düzinelerce test türü vardır, ancak bu beş yaygın tür son derece etkili bir kombinasyon oluşturur:

• Birim testleri , yöntemlerini doğrudan çağırarak yalıtılmış bir modülü test etmek için kullanılır. Bağımlılıklar test edilmiyor, bu nedenle alay ediliyor.
• Alt sistemleri test etmek için entegrasyon testleri kullanılır. Hala modülün kendi yöntemlerine doğrudan çağrılar kullanıyorsunuz, ancak burada bağımlılıkları önemsiyoruz, bu nedenle sahte bağımlılıklar kullanmayın—yalnızca gerçek (üretim) bağımlı modüller. Yine de bir bellek içi veritabanı veya sahte web sunucusu kullanabilirsiniz, çünkü bunlar altyapı taklitleridir.
• Fonksiyonel testler , uçtan uca (E2E) testler olarak da bilinen tüm uygulama için testlerdir. Doğrudan arama kullanmıyorsunuz. Bunun yerine, tüm etkileşim API veya kullanıcı arayüzü üzerinden gerçekleşir; bunlar, son kullanıcı perspektifinden yapılan testlerdir. Ancak, altyapı hala alay konusu.
• Kanarya testleri , işlevsel testlere benzer, ancak üretim altyapısı ve daha küçük bir eylem kümesi içerir. Yeni dağıtılan uygulamaların çalışmasını sağlamak için kullanılırlar.
• Yük testleri , kanarya testlerine benzer, ancak gerçek evreleme altyapısına ve birçok kez tekrarlanan daha da küçük bir dizi eyleme sahiptir.

Beş test türünün tamamıyla en baştan çalışmak her zaman gerekli değildir. Çoğu durumda, ilk üç testle uzun bir yol kat edebilirsiniz.

İhtiyaçlarınız için doğru olanları seçmenize yardımcı olmak için her türün kullanım durumlarını kısaca inceleyeceğiz.

Birim Testleri

Farklı fiyatlar ve kullanım tercihleri ​​​​ile örneği hatırlayın. Birim testi için iyi bir aday çünkü biz sadece modülün içinde ne olduğuyla ilgileniyoruz ve sonuçların önemli iş sonuçları var.

Modülde birçok farklı girdi parametresi kombinasyonu vardır ve her geçerli argüman kombinasyonu için geçerli bir dönüş değeri elde etmek istiyoruz. Birim testleri, işlevin veya yöntemin giriş parametrelerine doğrudan erişim sağladıkları ve her kombinasyonu kapsayacak düzinelerce test yöntemi yazmanız gerekmediği için geçerliliği sağlamada iyidir. Birçok dilde, kodunuz ve beklenen sonuçlar için gereken bağımsız değişkenleri kabul eden bir yöntem tanımlayarak test yöntemlerini tekrar etmekten kaçınabilirsiniz. Ardından, bu parametreli yöntem için farklı değerler ve beklentiler sağlamak için test araçlarınızı kullanabilirsiniz.

Entegrasyon Testleri

Entegrasyon testleri, bir modülün bağımlılıkları, diğer modüller veya altyapı ile nasıl etkileşime girdiğiyle ilgilendiğiniz durumlar için uygundur. Hala doğrudan yöntem çağrıları kullanıyorsunuz, ancak alt modüllere erişim yok, bu nedenle tüm alt modüllerin tüm giriş yöntemleri için tüm senaryoları test etmeye çalışmak pratik değildir.

Tipik olarak, modül başına bir başarı senaryosu ve bir başarısızlık senaryosu olmasını tercih ederim.

Bir bağımlılık enjeksiyon kabının başarıyla oluşturulup oluşturulmadığını, bir işleme veya hesaplama ardışık düzeninin beklenen sonucu verip vermediğini veya karmaşık verilerin bir veritabanından veya üçüncü taraf API'sinden doğru bir şekilde okunup dönüştürülmediğini kontrol etmek için entegrasyon testlerini kullanmayı seviyorum.

Fonksiyonel veya E2E Testleri

Bu testler, uygulamanızın en azından bir çalışma zamanı hatası olmadan başlayabileceğini doğruladıkları için uygulamanızın çalıştığına dair size en fazla güveni verir. Sınıflarına doğrudan erişim olmadan kodunuzu test etmeye başlamak biraz daha fazla iş, ancak ilk birkaç testi anlayıp yazdığınızda, çok zor olmadığını göreceksiniz.

Gerekirse komut satırı bağımsız değişkenleriyle bir işlem başlatarak uygulamayı çalıştırın ve ardından uygulamayı olası müşterinizin yapacağı gibi kullanın: API uç noktalarını çağırarak veya düğmelere basarak. Bu, UI testi durumunda bile zor değildir: Her büyük platformun, bir UI'de görsel bir öğe bulmak için bir aracı vardır.

Kanarya Testleri

İşlevsel testler, uygulamanızın bir test ortamında çalışıp çalışmadığını size bildirir, peki ya üretim ortamında? Birkaç üçüncü taraf API ile çalıştığınızı ve bunların durumlarını gösteren bir gösterge panosuna sahip olmak istediğinizi veya uygulamanızın gelen istekleri nasıl ele aldığını görmek istediğinizi varsayalım. Bunlar, kanarya testleri için yaygın kullanım durumlarıdır.

Üçüncü parti sistemlere yan etki yaratmadan kısaca çalışan sisteme etki ederek çalışırlar. Örneğin, yeni bir kullanıcı kaydedebilir veya sipariş vermeden ürün kullanılabilirliğini kontrol edebilirsiniz.

Kanarya testlerinin amacı, tüm ana bileşenlerin bir üretim ortamında birlikte çalıştığından, örneğin kimlik bilgisi sorunları nedeniyle başarısız olmadığından emin olmaktır.

Yük Testleri

Yük testleri, çok sayıda kişi kullanmaya başladığında uygulamanızın çalışmaya devam edip etmeyeceğini ortaya çıkarır. Kanarya ve işlevsel testlere benzerler ancak yerel veya üretim ortamlarında yürütülmezler. Genellikle, üretim ortamına benzer özel bir hazırlama ortamı kullanılır.

Bu testlerin, üretim hizmetlerinin harici yük testinden memnun olmayabilecek ve bunun sonucunda ekstra ücret talep edebilecek gerçek üçüncü taraf hizmetleri kullanmadığını belirtmek önemlidir.

3. Test Türlerini Ayrı Tutun

Otomatik test planınızı tasarlarken, bağımsız olarak çalışabilmesi için her bir test türü ayrılmalıdır. Bu ekstra organizasyon gerektirse de, karıştırma testleri sorun yaratabileceğinden buna değer.

Bu testler farklıdır:

• Niyetler ve temel kavramlar (böylece onları ayırmak, "gelecekteki siz" de dahil olmak üzere, koda bakan bir sonraki kişi için iyi bir örnek teşkil eder).
• Yürütme süreleri (böylece önce birim testlerini çalıştırmak, bir test başarısız olduğunda daha hızlı bir test döngüsü sağlar).
• Bağımlılıklar (bu nedenle, yalnızca bir test türünde gerekli olanları yüklemek daha verimlidir).
• Gerekli altyapılar.
• Programlama dilleri (bazı durumlarda).
• Sürekli entegrasyon (CI) boru hattındaki veya dışındaki konumlar.

Çoğu dilde ve teknoloji yığınında, örneğin, tüm birim testlerini, işlevsel modüllerden sonra adlandırılan alt klasörlerle birlikte gruplandırabileceğinizi belirtmek önemlidir. Bu kullanışlıdır, yeni işlevsel modüller oluştururken sürtünmeyi azaltır, otomatikleştirilmiş yapılar için daha kolaydır, daha az dağınıklık sağlar ve testi basitleştirmenin bir başka yoludur.

4. Testlerinizi Otomatik Olarak Çalıştırın

Bazı testler yazdığınız bir durumu hayal edin, ancak birkaç hafta sonra deponuzu çektikten sonra bu testlerin artık geçmediğini fark ettiniz.

Bu, testlerin kod olduğu ve diğer tüm kod parçaları gibi korunmaları gerektiği konusunda hoş olmayan bir hatırlatmadır. Bunun için en iyi zaman, işinizi bitirdiğinizi düşündüğünüz andan ve her şeyin hala istendiği gibi çalışıp çalışmadığını görmek istediğiniz andan hemen öncesidir. Gereken tüm içeriğe sahipsiniz ve kodu düzeltebilir veya başarısız testleri farklı bir alt sistem üzerinde çalışan iş arkadaşınızdan daha kolay değiştirebilirsiniz. Ancak bu an yalnızca zihninizde bulunur, bu nedenle testleri çalıştırmanın en yaygın yolu, geliştirme dalına bir göndermeden sonra veya bir çekme talebi oluşturduktan sonra otomatik olarak yapılır.

Bu şekilde, ana şubeniz her zaman geçerli bir durumda olacak veya en azından durumu hakkında net bir göstergeye sahip olacaksınız. Otomatik bir oluşturma ve test hattı veya bir CI ardışık düzeni aşağıdakilere yardımcı olur:

• Kodun oluşturulabilir olduğundan emin olun.
• Olası “Makinemde çalışıyor” sorunlarını ortadan kaldırın.
• Bir geliştirme ortamının nasıl hazırlanacağına ilişkin çalıştırılabilir yönergeler sağlayın.

Bu ardışık düzeni yapılandırmak zaman alır, ancak işlem hattı, tek geliştirici olsanız bile kullanıcılara veya istemcilere ulaşmadan önce bir dizi sorunu ortaya çıkarabilir.

CI, bir kez çalıştırıldığında, kapsamı genişletme şansı bulamadan yeni sorunları da ortaya çıkarır. Bu nedenle, ilk testi yazdıktan hemen sonra kurmayı tercih ediyorum. Kodunuzu GitHub'daki özel bir havuzda barındırabilir ve GitHub Eylemlerini ayarlayabilirsiniz. Deponuz herkese açıksa, GitHub Eylemlerinden bile daha fazla seçeneğiniz vardır. Örneğin, otomatikleştirilmiş test planım, veritabanı ve üç tür test içeren bir proje için AppVeyor'da çalışır.

Üretim projelerim için boru hattımı aşağıdaki gibi yapılandırmayı tercih ediyorum:

1. Derleme veya aktarma
2. Birim testleri: hızlıdırlar ve bağımlılık gerektirmezler
3. Veritabanının veya diğer hizmetlerin kurulumu ve başlatılması
4. Entegrasyon testleri: Kodunuzun dışında bağımlılıkları vardır, ancak işlevsel testlerden daha hızlıdırlar.
5. İşlevsel testler: diğer adımlar başarıyla tamamlandığında tüm uygulamayı çalıştırın

Kanarya testleri veya yük testleri yoktur. Spesifik ve gereksinimleri nedeniyle manuel olarak başlatılmalıdır.

5. Yalnızca Gerekli Testleri Yazın

Tüm kodlar için birim testleri yazmak yaygın bir stratejidir, ancak bazen bu zaman ve enerji harcar ve size güven vermez. "Test piramidi" kavramına aşinaysanız, kodunuzun tamamının, yalnızca diğer üst düzey testler tarafından kapsanan bir alt kümeyle birlikte birim testleriyle kapsanması gerektiğini düşünebilirsiniz.

Birkaç alaycı bağımlılığın istenen sırada çağrılmasını sağlayan bir birim testi yazmaya gerek görmüyorum. Bunu yapmak, birkaç deneme kurmayı ve tüm çağrıları doğrulamayı gerektirir, ancak yine de bana modülün çalıştığına dair güven vermez. Genellikle, yalnızca gerçek bağımlılıkları kullanan ve yalnızca sonucu kontrol eden bir entegrasyon testi yazarım; bu bana test edilen modüldeki boru hattının düzgün çalıştığına dair biraz güven veriyor.

Genel olarak fonksiyonelliği uygularken ve daha sonra desteklerken hayatımı kolaylaştıran testler yazıyorum.

Çoğu uygulama için, %100 kod kapsamını hedeflemek, çok fazla sıkıcı iş ekler ve genel olarak testler ve programlama ile çalışmanın keyfini ortadan kaldırır. Martin Fowler'ın Test Kapsamı'nın belirttiği gibi:

Test kapsamı, bir kod tabanının test edilmemiş kısımlarını bulmak için kullanışlı bir araçtır. Test kapsamı, testlerinizin ne kadar iyi olduğunun sayısal bir ifadesi olarak pek kullanılmaz.

Bu nedenle, bazı testler yazdıktan sonra kapsama analizörünü kurmanızı ve çalıştırmanızı tavsiye ederim. Vurgulanan kod satırlarını içeren rapor, yürütme yollarını daha iyi anlamanıza ve kapsanması gereken keşfedilmemiş yerleri bulmanıza yardımcı olacaktır. Ayrıca alıcılarınıza, ayarlayıcılarınıza ve cephelerinize bakarak %100 kapsamın neden eğlenceli olmadığını anlayacaksınız.

6. Lego oynayın

Zaman zaman “Özel yöntemleri nasıl test edebilirim?” gibi sorular görüyorum. yapmazsın. Bu soruyu sorduysanız, bir şeyler zaten yanlış gitti. Genellikle bu, Tek Sorumluluk İlkesini ihlal ettiğiniz ve modülünüzün düzgün bir şey yapmadığı anlamına gelir.

Bu modülü yeniden düzenleyin ve önemli olduğunu düşündüğünüz mantığı ayrı bir modüle çekin. Lego tuğlaları olarak yapılandırılmış koda yol açacak olan dosya sayısını artırmakta sorun yok: çok okunabilir, bakımı yapılabilir, değiştirilebilir ve test edilebilir.

Kodu düzgün bir şekilde yapılandırmak, söylemek yapmaktan daha kolaydır. İşte iki öneri:

Fonksiyonel Programlama

İşlevsel programlamanın ilkeleri ve fikirleri hakkında bilgi edinmeye değer. C, C++, C#, Java, Assembly, JavaScript ve Python gibi çoğu yaygın dil sizi makineler için program yazmaya zorlar. Fonksiyonel programlama insan beynine daha uygundur.

Bu ilk başta mantıksız görünebilir, ancak şunu düşünün: Tüm kodunuzu tek bir yönteme koyarsanız, geçici değerleri depolamak için paylaşılan bir bellek yığını kullanırsanız ve makul miktarda atlama talimatı kullanırsanız bir bilgisayar iyi olacaktır. Ayrıca, optimizasyon aşamasındaki derleyiciler bazen bunu yapar. Ancak insan beyni bu yaklaşımı kolay kolay kaldıramaz.

Fonksiyonel programlama, sizi yan etkisi olmayan, güçlü tiplerle, anlamlı bir şekilde saf fonksiyonlar yazmaya zorlar. Bu şekilde bir fonksiyon hakkında akıl yürütmek çok daha kolaydır çünkü ürettiği tek şey dönüş değeridir. Programming Throwdown podcast bölümü Adam Gordon Bell ile Fonksiyonel Programlama temel bir anlayış kazanmanıza yardımcı olacak ve Corecursive bölümleri ile devam edebilirsiniz. Son ikisi programlama algımı büyük ölçüde zenginleştirdi.

Test Odaklı Geliştirme

TDD'ye hakim olmanı tavsiye ederim. Öğrenmenin en iyi yolu pratik yapmaktır. String Calculator Kata, kod kata ile pratik yapmanın harika bir yoludur. Kata'da ustalaşmak zaman alacak ama sonuçta TDD fikrini tam olarak özümsemenize izin verecek, bu da çalışmak için bir zevk olan ve aynı zamanda test edilebilir olan iyi yapılandırılmış kod oluşturmanıza yardımcı olacak.

Bir uyarı notu: Bazen TDD'nin programlamanın tek doğru yolu olduğunu iddia eden TDD uzmanları göreceksiniz. Benim düşünceme göre, araç kutunuzdaki başka bir yararlı araç, başka bir şey değil.

Bazen modülleri ve süreçleri birbirine göre nasıl ayarlayacağınızı görmeniz ve hangi veri ve imzaları kullanacağınızı bilmemeniz gerekir. Bu gibi durumlarda, derlenene kadar kod yazın ve ardından işlevselliği gidermek ve hata ayıklamak için testler yazın.

Diğer durumlarda, istediğiniz girdiyi ve çıktıyı biliyorsunuz, ancak karmaşık mantık nedeniyle uygulamanın nasıl düzgün yazılacağı hakkında hiçbir fikriniz yok. Bu durumlarda, mükemmel uygulamayı düşünerek zaman harcamak yerine TDD prosedürünü izlemeye başlamak ve kodunuzu adım adım oluşturmak daha kolaydır.

7. Testleri Basit ve Odaklanmış Tutun

Gereksiz dikkat dağıtıcılar olmadan düzgünce organize edilmiş bir kod ortamında çalışmak bir zevktir. Bu nedenle, gerektiğinde yeniden düzenlemeden yararlanarak SOLID, KISS ve DRY ilkelerini testlere uygulamak önemlidir.

Bazen, "Yoğun bir şekilde test edilmiş bir kod tabanında çalışmaktan nefret ediyorum çünkü her değişiklik düzinelerce testi düzeltmemi gerektiriyor" gibi yorumlar duyuyorum. Bu, odaklanmayan ve çok fazla test etmeye çalışan testlerin neden olduğu yüksek bakım gerektiren bir sorundur. “Bir şeyi iyi yapın” ilkesi testler için de geçerlidir: “Bir şeyi iyi test edin”; her test nispeten kısa olmalı ve yalnızca bir kavramı test etmelidir. “Bir şeyi iyi test edin”, test başına bir iddiayla sınırlı olmanız gerektiği anlamına gelmez: Önemsiz ve önemli veri eşlemeyi test ediyorsanız düzinelerce kullanabilirsiniz.

Bu odak, belirli bir test veya test türü ile sınırlı değildir. ERP sisteminden gelen verileri yapınızla eşleştirmek gibi birim testleri kullanarak test ettiğiniz karmaşık mantıkla uğraştığınızı ve sahte ERP API'lerine erişen ve sonucu döndüren bir entegrasyon testiniz olduğunu hayal edin. Bu durumda, entegrasyon testlerinde eşlemeyi tekrar test etmemeniz için birim testinizin zaten neleri kapsadığını hatırlamak önemlidir. Genellikle, sonucun doğru tanımlama alanına sahip olduğundan emin olmak yeterlidir.

Lego tuğlaları gibi yapılandırılmış kodlar ve odaklanmış testler ile iş mantığındaki değişiklikler acı verici olmamalıdır. Değişiklikler radikal ise, dosyayı ve ilgili testleri bırakmanız ve yeni testlerle yeni bir uygulama yapmanız yeterlidir. Küçük değişiklikler durumunda, yeni gereksinimleri karşılamak ve mantıkta değişiklikler yapmak için genellikle bir ila üç testi değiştirirsiniz. Testleri değiştirmek iyidir; Bu uygulamayı çift girişli defter tutma olarak düşünebilirsiniz.

Sadeliğe ulaşmanın diğer yolları şunlardır:

• Test dosyası yapılandırması, test içeriği yapılandırması (tipik olarak bir Arrange-Act-Assert yapısı) ve test adlandırması için kuralların ortaya çıkması; sonra, en önemlisi, bu kuralları tutarlı bir şekilde takip etmek.
• Büyük kod bloklarını “istek hazırla” gibi yöntemlere çıkarmak ve tekrarlanan eylemler için yardımcı işlevler yapmak.
• Test verisi yapılandırması için oluşturucu kalıbının uygulanması.
• (Entegrasyon testlerinde) ana uygulamada kullandığınız aynı DI kapsayıcısını kullanma, böylece her örnekleme, manuel olarak bağımlılıklar oluşturmadan TestServices.Get() kadar önemsiz olacaktır. Bu şekilde, zaten yararlı yardımcılarınız olduğundan, yeni testleri okumak, sürdürmek ve yazmak kolay olacaktır.

Bir testin çok karmaşık hale geldiğini düşünüyorsanız, durun ve düşünün. Modülün veya testinizin yeniden düzenlenmesi gerekiyor.

8. Hayatınızı Kolaylaştıracak Araçları Kullanın

Test ederken birçok sıkıcı görevle karşılaşacaksınız. Örneğin, test ortamlarını veya veri nesnelerini ayarlama, bağımlılıklar için taslakları ve taklitleri yapılandırma vb. Neyse ki, her olgun teknoloji yığını, bu görevleri çok daha az sıkıcı hale getirmek için çeşitli araçlar içerir.

Henüz yapmadıysanız, ilk yüz testinizi yazmanızı, ardından tekrarlayan görevleri belirlemek için biraz zaman ayırmanızı ve teknoloji yığınınız için testle ilgili araçlar hakkında bilgi edinmenizi öneririm.

İlham almak için, kullanabileceğiniz bazı araçlar şunlardır:

• Test koşucuları. Kısa sözdizimi ve kullanım kolaylığı arayın. Deneyimlerime göre, .NET için xUnit'i öneririm (ancak NUnit de sağlam bir seçimdir). JavaScript veya TypeScript için Jest ile gidiyorum. Araçlar ve zorluklar geliştiğinden, görevleriniz ve zihniyetiniz için en iyi eşleşmeyi bulmaya çalışın.
• Kitaplıkları alay etmek . Arayüzler gibi kod bağımlılıkları için düşük seviyeli taklitler olabilir, ancak web API'leri veya veritabanları için daha yüksek seviyeli taklitler de vardır. JavaScript ve TypeScript için Jest'e dahil edilen düşük seviyeli alaylar uygundur. .NET için. Moq kullanıyorum, ancak NSubstitute da harika. Web API alaylarına gelince, WireMock.NET'i kullanmaktan zevk alıyorum. Yanıt işlemede sorun gidermek ve hata ayıklamak için API yerine kullanılabilir. Otomatik testlerde de oldukça güvenilir ve hızlıdır. Veritabanları, bellek içi karşılıkları kullanılarak alay edilebilir. .NET'teki EfCore böyle bir seçenek sunar.
• Veri oluşturma kitaplıkları . Bu yardımcı programlar, veri nesnelerinizi rastgele verilerle doldurur. Örneğin, büyük bir veri aktarım nesnesinden yalnızca birkaç alanla ilgilendiğinizde (eğer öyleyse; belki yalnızca eşleme doğruluğunu test etmek istiyorsanız) kullanışlıdırlar. Bunları testler için ve ayrıca bir formda görüntülemek veya veritabanınızı doldurmak için rastgele veriler olarak kullanabilirsiniz. Test amacıyla .NET'te AutoFixture kullanıyorum.
• UI otomasyon kitaplıkları . Bunlar, otomatik testler için otomatik kullanıcılardır: Uygulamanızı çalıştırabilir, formları doldurabilir, düğmelere tıklayabilir, etiketleri okuyabilir vb. Uygulamanızın tüm öğelerinde gezinmek için koordinatlara göre tıklama veya görüntü tanıma ile uğraşmanıza gerek yok; büyük platformlar, türe, tanımlayıcıya veya verilere göre gerekli öğeleri bulmak için araçlara sahiptir, böylece her yeniden tasarımda testlerinizi değiştirmeniz gerekmez. Sağlamdırlar, dolayısıyla sizin ve CI için çalışmasını sağladıktan sonra (bazen işlerin yalnızca sizin makinenizde çalıştığını öğrenirsiniz) çalışmaya devam ederler. .NET için FlaUI ve JavaScript ve TypeScript için Cypress kullanmaktan keyif alıyorum.
• Onay kitaplıkları . Çoğu test çalıştırıcısı onaylama araçlarını içerir, ancak bağımsız bir aracın, Fluent Assertions for .NET gibi daha temiz ve daha okunabilir sözdizimi kullanarak karmaşık iddialar yazmanıza yardımcı olabileceği durumlar vardır. Özellikle, bir öğenin sırasına veya bellekteki adresine bakılmaksızın koleksiyonların eşit olduğunu iddia etme işlevini seviyorum.

Akış Sizinle Olsun

Mutluluk, Akış: Optimal Deneyimin Psikolojisi kitabında ayrıntılı olarak açıklanan "akış" denen deneyimle sıkı sıkıya bağlıdır. Bu akış deneyimini elde etmek için, net hedefleri olan bir faaliyette bulunmanız ve ilerlemenizi görebilmeniz gerekir. Görevler, otomatik testlerin ideal olduğu anında geri bildirimle sonuçlanmalıdır. Ayrıca, her bireye bağlı olan zorluklar ve beceriler arasında bir denge kurmanız gerekir. Testler, özellikle TDD ile yaklaşıldığında size rehberlik edebilir ve güven aşılayabilir. Geçilen her test ilerlemenizin bir göstergesi olarak belirli hedefler belirlemenize yardımcı olur.

Doğru test yaklaşımı sizi daha mutlu ve daha üretken yapabilir ve testler tükenmişlik olasılığını azaltır. Anahtar, testi, kodunuzu geleceğe hazır hale getirmek için külfetli bir adım olarak değil, günlük geliştirme rutininizde size yardımcı olabilecek bir araç (veya araç seti) olarak görmektir.

Test etme, yazılım mühendislerinin çalışma yöntemlerini geliştirmelerine, en iyi sonuçları vermelerine ve zamanlarını en iyi şekilde kullanmalarına olanak tanıyan programlamanın gerekli bir parçasıdır. Belki daha da önemlisi, testler geliştiricilerin çalışmalarından daha fazla keyif almalarına yardımcı olarak morallerini ve motivasyonlarını artırır.