Test Odaklı Gelişme (TDD) Neden Sağlam Kodlama İçin En İyi Yoldur? | 2019-2020
Önce birim testleri yaz, sonra kodu yaz.
Birkaç yıl önce, “Test Odaklı Gelişme” yi ilk duyduğumda şüpheliydim.
“Önce birim testi, sonra kodu yazın” fikri bana saçma geldi.
Neden olmasın ki? Önce birim testlerini yaz? Kim böyle saçma bir şey yapar ki?
Fakat o zamana kadar 10 yıldan beri profesyonel bir programcı oldum ve sektörde bazı şeylerin gelip gittiğini gördüm. Özellikle geliştiriciler bu konuda çok beceriksizken, bir şeyi elden çıkarmaktan daha iyi biliyordum.
Bu yüzden bana basit bir örnek gösteren bir arkadaşıma danışmıştım.
Bu temel örnek, SUM yöntemiyle bir LCL_SUM sınıfına sahiptir. Bu yöntemin sorumluluğu sayıları toplamaktır. Bir içe aktarma parametresi olarak bir sayı alır ve sonucu türetmek için kendisine ekler. Bu yöntemi üretim yöntemi olarak adlandıralım.
Sınıfın kodu şuydu:
SINIF lcl_sum TANIM.
YÖNTEMLER: TOPLAM İTHALAT iv_1 TİPİ
DÖNÜŞ DEĞERİ (rv_sum) TİPİ i.
ENDCLASS. “Lcl_sum TANIM
* Henüz burada bir şey yok
SINIF lcl_sum UYGULAMA.
rv_sum = iv_1 * iv_1. “Kasıtlı hata (eklemek yerine çoğalırım)
ENDCLASS. “Lcl_sum UYGULAMA.
Test sınıfı kurulumu
Şimdi bir test sınıfı olarak hareket eden bir sınıf oluşturun. SAP’da, sınıfı tanımlarken FOR TESTING anahtar kelimesini eklemeniz gerekir. Bu ekleme, bu sınıfı üretim kodundan ayırır.
SINIF lcl_test TEST İÇİN TANIM
YÖNTEMLER: Test için m_sum.
ENDCLASS. “Lcl_test TANIM
SINIF lcl_test UYGULAMA.
ENDCLASS. “Lcl_test UYGULAMA
Test yöntemi uygulaması
Bu test yönteminde yapmanız gereken şey - Üretim kodunu test etmek. Bu nedenle, LCL_SUM yönteminin SUM yöntemini test edebilmek için, LCL_SUM nesnesine bir nesne başvurusu başlatmanız, yapay değeri gönderme yöntemini SUM olarak çağırmanız gerekir.
Dummy değerine göre, yöntem size sonucu gönderir - yöntemden gerçek sonuç. Kukla değere dayanarak, beklenen değerin ne olacağını biliyorsunuz. Örneğin. 3 sayısını SUM yöntemine geçirirseniz, bu değer 3'e eklerken 6 sonucunu verir.
Gerçek sonucu test edilen üretim kodundan veya yöntemden aldığınızda, sonuçları karşılaştırmanız gerekir. Beklenen gerçekle beklenen eşleşme değilse, sisteme gerçekle Beklenen ile ilgili bir sorun olduğunu bildirmeniz ve uygun bir mesaj göstermeniz gerekir.
VERİ: o_cut TYPE REF TO lcl_sum.
VERİ: lv_result TİPİ i.
AMAÇ OBJECT o_cut.
act = lv_result
msg = 'çıktıda yanlış bir şey'
Birim testi sonuçları
Bu bana üretim yöntemi uygulamasında yanlış bir şey olduğunu söylüyor.
Evet, SUM yönteminin uygulanmasına yakından bakarsanız, Summation kullanmaya ilişkin bir yazım hatası var, Ben Çarpma kullanmıştım. Bu nedenle, düzeltip başarılı bir şekilde yürütmek için testi yeniden yapacağım.
TDD'ye bağladım. Flabbergasted doğru kelime olurdu.
Şaşırtıcı olan şey, geliştirme ve testlerin son derece azalan döngü süresiydi.
Derlemeye veya çalıştırmaya çalışmadan önce bir saatin daha iyi bir kısmı için kod yazmaya alışmıştım. Ancak burada kod her 2 dakikada bir çalıştırılıyor ve test ediliyordu.
Böylece, kısaca TDD, “ilk önce birim testlerini yazdıktan sonra kodu, sonra yeniden yazmayı ve sonra tekrar etmeyi” kuralını izleyen kısa gelişim döngüleri ile gerçekleştirilir. Birim testleri, işlevlerin beklendiği gibi çalışıp çalışmadığını kontrol eden otomatik testlerdir. İlk ünite testiniz başarısız oldu, çünkü daha önce kod kodunuz bile yoktu.
Test durum koduna bir bit ekleyin. Üretim koduna biraz ekleyin. İki kod akışı aynı anda tamamlayıcı bileşenlere dönüşür. Testler, bir antijene uyan bir antikor gibi üretim koduna uyar.
Bu önlem, geliştiricilerin verilen testle uyumlu olmayan gereksiz kodlar yazmalarını önler.
Ve bu bütünleşik yaklaşım, geliştiriciye bir fayda sağlar.
Hiçbir Şeyi Kırmadan Kötü Kodu Düzelt.
Ne zaman kötü kod görürseniz, gözlerinizi yuvarlayın, Tanrı'ya dua edin ve iki ifadeden birini söyleyin.
· “Bu bir karmaşa. Sanırım bir şekilde düzeltmek zorundayım ”.
Her iki durumda da, bir korku unsuru var. Aslında belirsizlik.
Ya kodum mevcut işlevselliği bozarsa?
TDD, tam olarak bu belirsizliğin üstesinden gelmenize yardımcı olur.
TDD ortamında, geliştiricilerin, kod yazıldıktan sonra bunları ortadan kaldırmak yerine hataları önlemek için testler yapmaya odaklandıklarını belirtmek önemlidir. Bu TDD'nin en güçlü faydalarından biridir. Güvendiğiniz bir test grubunuz olduğunda, değişiklik yapma korkusuyla kaybedersiniz. Kötü kod gördüğünüzde, sadece yerinde temizleyin.
Kodunuzu düzenli tutarsanız, ekibinizin yeni özellikler eklemek veya mevcut kod tabanını değiştirmek için daha az çaba harcaması gerekir.
TDD Belgeleri Güçlendirir.
Dick Brandon gözlemlendiğinde çiviye vurmuş.
“Belgeleme seks gibidir; iyi olduğunda, çok, çok iyi ve kötü olduğunda, hiç yoktan iyidir. ”
Belgelendirme, programlamanın hint yağıdır. Yöneticiler, programcılar için iyi olduğunu düşünüyor ve programcılar bundan nefret ediyor!
Kapsam sünmesinin oluşmasının yaygın bir nedeni, açıkça tanımlanmış şartlara sahip dokümantasyon eksikliğidir. Bu sorun, test odaklı geliştirme yoluyla hafifletilebilir.
TDD ortamında, geliştiriciler kodun belirli bölümlerini test etmek için birim testleri yazar. Birim testleri, uygulanması gereken kesin özellikleri tanımlayan özellikler olarak hizmet eder. Bu nedenle, iyi tanımlanmış testler geliştiricilerin gereksiz kod yazmasını önler.
Ve bu birim testleri belgelerdir. Sistemin en alt düzey tasarımını tanımlarlar. Belirsiz, doğru, izleyicinin anlayacağı bir dilde yazılmış ve yürütecekleri kadar resmi. Var olabilecek en iyi düşük seviye dokümantasyon türüdür.
TDD, Daha İyi Tasarımda Yardımcı Olur
TDD’nin temel ön koşulu, kod yazmadan önce birim test durumlarınızı yazmanız gerektiğidir.
Test koduyla ilgili sorun, bu kodu izole etmenizdir. Bir işlevi başka işlevler çağırırsa, bir işlevi test etmek genellikle zordur. Bu testi yazmak için, işlevi diğerlerinden ayırmanın bir yolunu bulmalısınız. Başka bir deyişle, ilk önce sınama ihtiyacı sizi iyi tasarım hakkında düşünmeye zorlar.
Bu, kod geliştikçe işler üzerinde daha iyi kontrol sahibi olduğunuz daha iyi, ayrık bir tasarım yaratır.
Test senaryolarını önceden yazarken başlangıçta zaman alabilir ancak bu birçok yarar sağlar. Geliştiriciler, daha önce kod satırları yazdıklarını, çözümlerinin alakasız olduğunu fark ettiklerini ve daha sonra sıfırdan yeniden kodlamaya başladıklarını itiraf ediyorlar.
Eski kodlama uygulamalarından farklı olarak TDD, geliştiricilerin çizim tahtasına geri dönmelerini ve hafif, esnek bir mimari tasarlamaya odaklanabilmelerini sağlar.
Ve önceden test senaryoları yazmak gerçeği, daha sonra ortaya çıkabilecek hataları önler, böylece zamandan, emekten ve mide ekşimesinden tasarruf edilir.
Ve Son olarak TDD En İyi Kodlama Uygulamalarını İzler.
TDD, DRY, KISS, YAGNI ve SOLID gibi iyi kodlama prensiplerini teşvik eder.
DRY (Kendinizi Tekrar Etmeyin) ilkesi, geliştiricilere aynı sistemin farklı bölümlerinde aynı kodu tekrar etmekten kaçınmaları gerektiğini söyler, bu yüzden bazen DIE ilkesi (Çoğaltma Evil) olarak da adlandırılır. DRY, geliştiricilerin, sistem işlevselliğini kapsama almak ve tutarlı bir kod temeli sağlamak için sınıfları ve işlevleri kullanmalarını önerir.
KISS (Basit Tutun, Aptal!) İlkesi, geliştiricilere tekerleği yeniden icat etmemelerini, basit ve açık mimariler inşa etmelerini önerir. KISS'in özü aşırı mühendislik çözümlerinden kaçınmaktır.
YAGNI (Buna İhtiyacınız Yok) prensibi altın kaplama ile savaşıyor. Altın kaplama, özellikle bir geliştirici müşteriyi memnun etmek için mevcut işlevselliği geliştirmek için istekliyse zararsız görünebilir. Ancak, proje gecikmesine veya hoşnutsuz bir müşteriye neden olabilecek ilave geliştirme süresiyle sonuçlanır. YAGNI bunu açıkça ortaya koyuyor: Bir geliştirici yalnızca atanmış görevleri yerine getirmeli ve aşırı işlevsellik eklemekten kaçınmalıdır.
KATI tek bir sorumlulukta beş ilkeden oluşur: tek sorumluluk, Açık-kapalı, Liskov ikamesi, arayüz ayrımı ve bağımlılık inversiyonu. Kısaca, SOLID, bu ilkelerin izlenmesinin, uygulamaların sürdürülmesini ve test edilmesini kolaylaştırdığını belirtir.
Özet olarak, TDD bakımı kolay, zarif ve basit bir kod oluşturulmasına yardımcı olur.
Robert Martin'in dediği gibi.
“Temiz kod her zaman umurunda olan biri tarafından yazılmış gibi görünüyor.”
Aşırı Programlama: Kent Beck.
Çevik Yazılım Geliştirme: Robert Martin
Yeniden düzenleme: Martin Fowler
Ravi Rajan Hindistan Mumbai'de bulunan global bir IT program yöneticisidir. Aynı zamanda hevesli bir blog yazarı, Haiku şiir yazarı, arkeoloji meraklısı ve tarih manyağı. LinkedIn, Orta ve Twitter'da Ravi ile bağlantı kurun.
Bu hikaye, Orta’nın en büyük girişimcilik yayını olan Startup’ta ve ardından +438.678 kişi tarafından yayınlandı.