Teste giriş

Testle ilgili her şey hakkında yeni blog serimize hoş geldiniz. Umarım bu blog yazıları, onları burada Mediatoolkit'te nasıl yazdığımız ve neden hakkında genel bir fikir verir. Örneklere dalmadan önce, test yazmanın bazı temel tanımları, fikirleri ve yararları ile başlayalım.

Ne tür testler var?

Tüm testler eşit oluşturulmaz. Farklı amaçlar için farklı testler vardır. Bu gönderi esas olarak birim testlerine odaklansa da, farklılıkların farkında olmalı ve her birinin faydalarını anlamalıyız.

1. Manuel testler

Manuel test, bir test cihazı tarafından manuel olarak yürütülen testleri içerir. Bunlar genellikle Kalite Güvencesi veya geliştiricilerin kendileri tarafından yapılır. QA, ana uygulama test cihazı değil, son savunma hattı olarak görülmelidir (UI testinin ana yolu olarak QA'nın manuel test yapması bu durum için geçerli bir istisnadır).

Geliştiriciler genellikle bazı şeyleri yerel olarak çalıştırmak istediklerinde manuel testler yazarlar ve herhangi bir kodu hazırlama aşamasına veya Tanrı sizi korusun üretime zorlamadan sistemin nasıl davrandığını görürler . Ancak bu testlerin amacı kodun sağlamlığı değildir. Bu testlerin tek rolü, hataları yakalamak ve ürününüzün kalitesini sağlamaktır .

2. Entegrasyon testleri

Sistemler birden çok bileşenden oluşur veya en azından öyle olmalıdır. Entegrasyon testleri, bu bileşenlerin genel API'sini kontrol eder . Yalnızca REST API'si değil, Kafka konu iletişiminiz gibi herkese açık tüm API'ler.

Bir bileşen "diyorsa", belirli bir formatta bir konu hakkında bir mesaj verir, bu onun genel API'si veya sözleşmesidir. Entegrasyon testi, bireysel olarak geliştirilmiş birden fazla bileşenin iletişim kurup kuramadığını ve sözleşmelerinin bir grup olarak eşleşip eşleşmediğini kontrol eder.

Bu bileşenleri yalnızca tek tek test ederseniz, bireysel davranışları doğru çalışabilir, ancak bunları daha büyük bir grup içinde birleştirmeye çalıştığınızda sözleşmelerinin farklı olduğunu keşfedersiniz .

3. Uçtan uca (E2E) testler

Uçtan uca testler, son ürünün kullanıcı deneyimi akışını sağlar . Günümüzde sistemlerin karmaşıklığını testlerle kapatmak zordur. Birçok sistem birbirine güvenir ve E2E testleri ürünün bekleneni yapmasını sağlar. QA, son kullanıcı akışından geçerek ve tüm sistemlerin beklendiği gibi davranıp davranmadığını kontrol ederek ürününüzün doğruluğunu onaylar.

4. Birim testleri

Birim testleri , herhangi bir güvenilir yazılımın belkemiğidir . Diğer testler için temel oluştururlar. Bireysel birimleri test ederler.

Geliştiriciler, bir birimin tanımını tek bir yöntemle karıştırabilir. Birim testleri, birden çok farklı sınıftan oluşabilen bir bileşenin davranışını test etmelidir. Diğer bileşenler tarafından erişilebilen genel yöntemlerin test edilmesi gerekir, korumalı yöntemleri veya sınıfları test etmeyin. Bunlar, genel API'nizin parçası değil, uygulama ayrıntılarıdır .

Neden test edelim ki?

İyi testler yazıp sık sık yazarsak, ürünümüzün kalitesini daha gün yüzüne çıkmadan sağlayabiliriz.

Sistemimiz yaşlandıkça, test etmenin faydaları giderek daha belirgin hale geliyor. Ortamlarımız güvenilir hale gelir, geliştirme süresinden ve kaçınılmaz olarak işler ters gittiğinde çok fazla zahmetten tasarruf sağlar. Meslektaşlarınız, testlerinize bir göz atabildiklerinde ve bir şeyleri manuel olarak çalıştırmak zorunda kalmadan kodunuzun ne yapması ve ne yapmaması gerektiğini anladıklarında minnettar olacaklardır.

sağlam kod

“Sağlam kod”dan bahsetmeye başlamadan önce onu nasıl tanımlamalıyız? Kodu sağlam yapan nedir? Bu, savunmacı bir şekilde programlamamız ve diğer geliştiricilerin kodumuzu nasıl kötüye kullanabileceğini düşünmemiz gerektiği anlamına mı geliyor?

Sağlam kod her zaman basit ve temizdir. Sadelik sağlamdır, karmaşıklık kırılgandır . Geçersiz girdileri ele almalıyız, ancak bu, defansif olarak programlamamız ve ekibimize güvenmememiz gerektiği anlamına gelmez.

Gall Yasası : Çalışan karmaşık bir sistemin, her zaman, çalışan basit bir sistemden evrimleştiği bulunur.

Ters önerme de doğru gibi görünüyor: sıfırdan tasarlanmış karmaşık bir sistem asla çalışmaz ve çalıştırılamaz. Çalışan basit bir sistemle başlayarak baştan başlamalısınız.

Güvenli bir şekilde yeniden düzenleme

Kodunuz testler kapsamında olduğunda, artık mevcut kodu değiştirmekten korkmazsınız . Her değişiklikten sonra testlerinizi çalıştırabilir ve bir şeyleri bozmadığınızdan emin olabilirsiniz. Testleriniz olduğunda, defansif olarak programlamanız gerekmez.

Testsiz yeniden düzenleme, uykusuz gecelerle ve Pazar günleri çalışmayla sonuçlanacak kaygan bir yokuştan aşağı iniyor. Bu konu burada ele alınamayacak kadar geniş ve gelecekte başlı başına bir blog gönderisini hak ediyor.

Nasıl test yazmıyoruz?

Birim testlerinin nasıl yazılacağını bilmek kadar, nasıl yazılacağını bilmek de önemlidir.

• Bir yöntem çağrısının sonucunu yazdıran bir test yazmak , istenen sonucu doğrulamadığımız için bir test değildir .
• Testiniz Belgeler klasörünüzdeki bir dosyadan veri okuyorsa, testler ortama bağlı olmaması gerektiğinden bu gerçek bir birim testi değildir.
• Herhangi bir geliştirici , başka bir şey yapmadan kodunuzu kontrol edebilmeli ve testleri başarıyla çalıştırabilmelidir.
• Her birim testi diğer testlerden bağımsız olmalıdır. Bu, testlerinizin yürütme sırasının da önemli olmaması gerektiği anlamına gelir.
• Herhangi bir kodu değiştirmezsek, testleri birden çok kez çalıştırmak her zaman aynı sonuçlarla bitmelidir .
• Birim testleri, bireysel yöntem çağrılarını değil, davranışları test etmelidir . Her sınıf ve yöntemin kendi testine sahip olması gerekmez.

Davranış , sisteminizin kullanıcısının ihtiyaç duyduğu gerçek değeri üreten bir şeydir. Kullanıcınızın, productFactory.create() in iki kez çağrıldığında aynı nesneyi yaratıp yaratmadığını veya havuzunuzun bazı parametrelerle çağrıldığını bilmesi gerekiyor mu? Muhtemelen hayır, ancak yine de birçok geliştirici tam olarak bu tür testler yazıyor.

Testleriniz böyle görünüyorsa, uygulamanızla sıkı sıkıya bağlıdırlar. Uygulamanızın ayrıntılarını her değiştirmek istediğinizde, davranış aynı olsa bile testlerinizi güncellemeniz gerekir. Testleriniz , uygulama ayrıntılarında değil, yalnızca davranış değiştiğinde değişmelidir . Başka bir deyişle, kodunuzun nasıl yaptığını değil, ne yaptığını test edin.

Testleri nasıl yazarız?

Testlerimiz en iyi kod uygulamalarını takip etmeli , ortamdan bağımsız olmalı ve hızlı yürütülmelidir .

Test yürütme süresini mümkün olduğunca kısa tutmak önemlidir. Her test birkaç milisaniyeden fazla sürmemelidir. Testlerin yürütülmesi çok uzun sürdüğünde, insanlar bunları atlama eğilimindedir ve dağıtım yürütülebilir dosyalarını oluşturamadığında yaygara yapmak için Jenkins gibi CI sunucularına güvenir.

Her test 3 'A' bölümünden oluşur (AAA modeli) :

1. Düzenlemek
2. davranmak
3. iddia

1. Düzenle

Testimizin düzenleme bölümünde, test etmek istediğimiz davranışı çağırmadan önce sistemimizin belirli bir durumda olduğundan emin oluyoruz . 'Sistem', davranış üretmek, geçici dosyalar veya bu türden şeyler yaratmak için belirli bir şekilde kurmamız gereken bir nesne olabilir.

Bu bölümdeki kod genellikle diğer ikisinin birleşiminden daha büyüktür .

Bu bölümü küçük tutmak için özellikle yararlı olması gereken bir tasarım deseni Object Mother . Bu tasarım deseni Factory çok benzer, ancak sizin için önceden yapılandırılmış nesneler oluşturan daha özel yöntemlere sahiptir. Standart bir Factory createCar(carDescription) gibi bir yöntemi olabilirken, bir ObjectMother createRedFerrari() , createBlackTesla() veya createBrokenYugo() gibi yöntemleri olacaktır.

2. Eylem

Testinizin bu bölümünde bir satır olmalıdır. Bu satır, test edilen davranışı yürütür. Kendinizi bu bölüm için birden fazla satır yazarken bulursanız, muhtemelen davranışınızın doğru kapsüllenmesine sahip değilsinizdir . Müşterilerinizin belirli bir sırayla nesnenizin birden çok yöntemini çağırması beklenmemelidir, peki neden testleriniz?

Bu satır, test etmek istediğimiz bir yöntem çağrısıdır. Bu yöntem bir sonuç döndürürse, Assert adımında beklenen değer olup olmadığını kontrol etmek için o değeri bir değişkende saklamanız gerekir.

3. İddia

Arrange kısmında sistemi hazırlayıp, Act kısmında test edilen eylemimizi gerçekleştirdikten sonra, action sonucunu doğrulamamız gerekiyor. Genellikle burada yöntemin sonucunu kontrol ederiz, ancak bazen yöntemlerimiz değer döndürmez, ancak yine de yan etkiler üretirler. Kodumuzun bir nesnenin durumunu değiştirmesi, bir dosya oluşturması veya bir List bir şey kaldırması bekleniyorsa, tam olarak bunu yapıp yapmadığını kontrol etmeliyiz.

Saplamalar ve Sahtekarlıklar

Çoğu geliştirici, sahte ve saplama terimlerini birbirinin yerine kullanır, ancak farklılıklar vardır.

Bir saplama testi geçemez, bir sahte kutu.

Saplamalar durum tabanlıdır , sabit kodlanmış değerler döndürürler. "Ne sonuç aldım?"

Alaylar davranışa dayalıdır , bunları davranışınızın içinden nasıl geçtiğini doğrulamak için kullanırsınız. "Sonucu nasıl aldım?"

Birim testleriniz alaylarla doluysa, testleriniz çok kırılgan olur, yani uygulama ayrıntılarınızdan birini her değiştirdiğinizde, tüm sahte çağrılarınızı güncellemeniz gerekir.

Tek bir şeyi test edin.

Bir davranışı izole edebilmemiz ve bunun işe yaradığını kanıtlayabilmemiz gerekir . Bu davranışın farklı girdilerle farklı çalışması gerekiyorsa, bu davranışların her biri için yeni bir test yazmamız gerekir. Aynı anda birden fazla şeyi test eden büyük bir testimiz varsa, testimizin neden başarısız olduğunu bilmek zor. Üstelik artık ihtiyacımız olmayan özellikleri kaldırmak ve yeni kod eklediğimizde hangi özellikleri bozduğumuzu görmek zorlaşıyor.

Test edilen davranışı birden çok kez çağırmanızı gerektirmediği sürece, testlerinizin son bölümünde birden fazla iddiaya sahip olmak gayet iyidir. Durum buysa, hatalı davranışı tespit etmek ve düzeltmek zor olacaktır.

Bir testte birden fazla davranışı öne sürdüğümüzde, tam olarak neyin işe yaramadığına dair net bir resim elde edemeyiz çünkü test yalnızca ilk başarısızlığı bildirir ve geri kalanlar atlanır. Hangi değişikliklerin gerekli olduğunu ve kaç şeyin beklendiği gibi çalışmadığını anlamak çok daha zor hale geliyor.

adlandırma testleri

İyi testleri harika testlerden ayıran şeylerden biri test adıdır. Testler bize sadece ne yaptıklarını değil, ne zaman yaptıklarını da söylemelidir.

Kullanabileceğiniz çok sayıda iyi adlandırma modeli vardır, bu nedenle en açıklayıcı bulduğunuz birini seçin ve buna bağlı kalın. İşte bazı harika test isimleri örnekleri:

• Kayıt HizmetiShould.createNewAccountWhenEmailIsNotTaken
• KayıtServiceTest.WhenEmailIsFree_createNewAccount
• KayıtServiceTest.if_freeEmail_When_userCreatesAccount_then_create

Birim testleri yazarken, test ettiğiniz şeyi iletmek , en iyi yöntem adlandırma uygulamalarını izlemekten çok daha önemlidir. Örneğin, Java'da metot yazarken camelCase kullanıyoruz, ancak durumu test adınızdaki eylemden ayırmak için alt çizgi (_) kullanmak tamamen geçerlidir.

temiz testler

Yazdığınız testler, kodunuza uyguladığınız tüm temiz kod uygulamalarını takip etmelidir. Testler ikinci sınıf vatandaş değildir ve onları okunabilir hale getirmek için kodunuzun geri kalanına gösterdiğiniz özenin aynısını uygulamanız gerekir.

Testlerde kod tekrarının tanımlanması çok önemlidir. KURU ilkesi (Kendini Tekrar Etme) aynı nedenle değişen davranışı ayıklamak için geçerlidir. Testler farklı nedenlerle değişir, bu nedenle aynı nedenden dolayı gerçekten değişmiyorlarsa, testlerinizden bir şeyler çıkarırken çeşitlendirin. Spoiler uyarısı, genellikle yapmazlar.

ifadeler testlere ait if . if ifadesi, testimizin en az iki farklı şey yaptığını ve testimizi iki farklı test olarak yeniden yazarsak daha iyi olacağımızı söyler. Doğru adlandırıldığında, testlerin ne yaptığını ve tüm farklı davranışların neler olduğunu anlamak daha kolay olacaktır.

Testleri ne zaman yazmalıyız?

TDD ilkeleri rehberliğinde yeni kod yazmadan önce testler yazmalıyız.

Yeni bir özellik eklememiz gerektiğinde öncelikle istenilen davranışı yeni bir test olarak tanımlıyoruz. Diğer testleri bozmadan bu testi geçmek için gereken en az miktarda değişiklik yapıyoruz.

Aksi takdirde, ne kadar çok zaman geçerse, o kadar çok test edilmemiş kodumuz olur ve hatalar veya aşırı mühendislik yapma şansımız artar .

Ayrıca, şu anda test edilecek daha fazla kodumuz olduğundan testler daha karmaşık hale geliyor ve genellikle olan şey, geliştiricilerin testleri koda göre ayarlamasıdır. Bu, davranışı, tersi yerine kodumuzun yaptığıyla eşleşecek şekilde ayarladığımız anlamına gelir.

Testleri erken yazdığımızda, sorunun tanımı küçülür ve daha genel ve karmaşık davranışlardan ziyade bu tür konulara kafa yormak daha kolaydır.

Son düşünceler

Test yazmak isteğe bağlı bir şey gibi görünse de, iyi temellerle başlamak çok önemlidir. Kodlama zaten zor , okunması, anlaşılması ve bakımı daha kolay, test edilebilir kodlar yazarak kendiniz ve ekip arkadaşlarınız için kolaylaştırın. Son olarak, testlerinizi isteklerinize uygun hale getirmekte zorluk çekiyorsanız, sorun testlerinize göre kodunuzda daha olasıdır.

Temiz ve test edilebilir bir kod üzerinde çalışmak ister misiniz?
Kıdemli Arka Uç Geliştiricisi için açık pozisyonumuza göz atın
veya bize açık bir başvuru gönderin!