TDD yaparken Logging'e ihtiyacımız var mı?

Kırmızı, Yeşil ve Refaktör döngüsünü yaparken, testi geçmek için her zaman minimum kodu yazmalıyız. TDD hakkında bilgi edindiğim ve neredeyse tüm kitapların süreci tarif ettiği yöntem bu.

Peki ya tomruklama?

Dürüst olmak gerekirse, bir uygulamada günlüğe kaydetmeyi nadiren kullandım, ancak gerçekten karmaşık olan bir şey olmadıkça, uygun günlüğe kaydetmenin önemi hakkında konuşan çok sayıda gönderi gördüm.
Bu nedenle, bir istisna kaydı yapmak dışında, uygun bir test uygulamasında (birim / entegrasyon / kabul testleri) oturum açmanın gerçek önemini haklı çıkaramadım.

Yani benim sorularım:

1. TDD yapıyorsak giriş yapmamız gerekiyor mu? başarısız bir test uygulamada neyin yanlış olduğunu ortaya çıkarmaz?
2. Her sınıftaki her bir yöntemde günlük kaydı için test eklemeli miyiz?
3. Örneğin üretim ortamında bazı günlük seviyeleri devre dışı bırakılmışsa, bu testler ve çevre arasında bir bağımlılık getirmez mi?
4. İnsanlar günlüklerin hata ayıklamayı nasıl kolaylaştırdığı hakkında konuşurlar, ancak TDD'nin temel avantajlarından biri, başarısız bir test nedeniyle neyin yanlış olduğunu her zaman bilmemdir.

Kaybettiğim bir şey var mı?

1) TDD yapıyorsak giriş yapmamız gerekiyor mu? başarısız bir test uygulamada neyin yanlış olduğunu ortaya çıkarmaz?

Bu, uygulamanızın ihtiyaç duyduğu her olası testi yaptığınızı varsayar, bu nadiren doğrudur. Günlükler, henüz testler yazmadığınız hataları izlemenize yardımcı olur.

2) Her bir sınıftaki her bir yöntemde günlüğe kaydetme işlemi için test eklemeli miyiz?

Kaydedicinin kendisi test edilirse, diğer bağımlılıklara benzer şekilde, her sınıfta tekrar test edilmesi gerekmez.

3) Örneğin üretim ortamında bazı günlük seviyeleri devre dışı bırakılmışsa, bu testler ve çevre arasında bir bağımlılık getirmez mi?

İnsanlar (ve kütük toplayıcıları) kütüklere bağlıdır, testler bunlara bağlı olmamalıdır. Tipik olarak birkaç kütük seviyesi vardır ve bazıları üretimde kullanılır ve bazı ilave seviyeler gelişimde benzer şekilde kullanılır:

"Rails log level üretim modunda bilgi ve geliştirme ve test aşamasında hata ayıklama" - http://guides.rubyonrails.org/debugging_rails_applications.html

Diğer uygulamalar da benzer bir yaklaşım kullanır.

4) İnsanlar günlüklerin hata ayıklamayı nasıl kolaylaştırdığı hakkında konuşurlar, ancak TDD'nin temel avantajlarından biri, başarısız bir test nedeniyle neyin yanlış olduğunu her zaman bilmemdir.

Üretim hataları tüm testleri geçti, bu nedenle bu sorunları araştırmak için başka bir referansa ihtiyacınız olabilir.

Günlük kaydı , bir uygulamanın istisnai olmayan davranışını açıklamakta kullanışlıdır :

Olay , sistemin faaliyetini anlamak ve sorunları teşhis etmek için kullanılabilecek bir denetim izi sağlamak amacıyla bir sistemin yürütülmesinde yer alan kayıt olaylarını günlüğe kaydeder . Karmaşık sistemlerin, özellikle kullanıcı etkileşimi az olan uygulamalarda ( sunucu uygulamaları gibi ) anlaşılması için çok önemlidirler ...

Uygulamanın nasıl test edildiğine ve istisnaların ne kadar iyi günlüğe kaydedildiğine bakılmaksızın, kullanıcıları sorabilir,

Programınızın çıktısı 0 olurken 1 olur, neden bu?

İstisnai olmayan davranışını açıklamak için uygulama config, parametreler ve diğer çalışma zamanı ayrıntılarının ne olduğunu doğrulamak için günlüğe kaydetmeniz gerekir.

Yukarıdaki açıdan bakıldığında, günlük oluşturma, geliştirmeye göre daha fazla desteğe yöneliktir . Uygulama yayına girdikten sonra, programcıların daha fazla gelişmeye odaklanmalarını sağlamak için bir başkasının kullanıcılardan gelen soruları ele almasına izin verilmesi arzu edilir.

Hangi uygulamanın yaptığını günlüğe kaydetmek, bir başkasının , kodun içine girmeden ve geliştiricilerin dikkatini dağıtmadan, neler olup bittiğini açıklama istekleriyle program davranışını anlamasını sağlar .

Buradaki çoğu cevap doğruluk yönüne odaklanır. Ancak, günlük kaydı da farklı bir amaca hizmet eder: Günlük, performansla ilgili verileri toplamanın bir yolu olabilir. Böylece sistem hatasız çalışıyor olsa bile, bir günlük neden yavaş olduğunu söyleyebilir. Test paketinin tüm yönleriyle tam olarak kapsanması durumunda bile bir test paketi anlatmaz.

Elbette, performans açısından kritik bir sistem bazı operasyonel panele kilit performans ölçümleri sağlayabilir / sağlamalıdır, ancak “klasik” kayıt farklı bir ayrıntı seviyesi sağlayabilir.

Asıl sorunuza kısa cevap: Genel bir kural olarak, kodunuzdaki hatalar TDD tarafından karşılanmayacaktır. Bazıları , ideal olarak birçoğu olabilir, ancak başarısız testlerin olmaması, böceklerin yokluğunu göstermez. Bu, yazılım testlerinde çok önemli bir maksimumdur.

Sisteminizde yanlış bir davranış olup olmayacağınızı bilemeyeceğinizden, belki de nadir şartlar altında, kayıt işlemi kaçınılmaz bir şekilde yanlış gittiğinde neyin yanlış olduğunu anlamanıza yardımcı olabilecek kullanışlı bir araçtır.

Günlük kaydı ve TDD farklı endişeleri ele almaktadır.

1. % 100 test kapsamınız yoksa, genellikle durum böyle değildir, yazılımınızın asla çökmeyeceğini bilemezsiniz (EDIT: ve - yorumlarda belirtildiği gibi - olsa bile, yazılımınızdan bağımsız bir şey olabilir) Bir çarpışma); Bu kesinlikle hiçbir hataya sahip olmayan bir yazılım yapabileceğinizi düşünmekle aynıdır (NASA bile yapamaz). Dolayısıyla, en azından, programınızın çökmesi durumunda muhtemel arızaları kaydetmeniz gerekir, böylece nedenini öğrenebilirsiniz.

2. Günlük, kullandığınız teknolojiye bağlı olarak harici bir kütüphane veya intern çerçeve tarafından yapılmalıdır. Bununla demek istediğim, daha önce test edilmiş bir şey olması ve kendinizi test etmeniz gerekmiyor. Her yöntemin olması gereken şeyleri kaydettiğini test etmek çok zor.

3. Günlükler testler için uygun değildir, hiçbir bağımlılık olmamalıdır. Bununla birlikte, günlükler çevreye karşılık gelen bir dosyada saklanmalıdır (test, geliştirme ve üretim ortamı için farklı bir dosyaya sahip olmalısınız). en sonunda).

4. Bir hata çok net olmayabilir ve bir TDD testi başarısız olduğunda neyin yanlış gittiği her zaman açık değildir. Günlükleri daha kesin olmalıdır. Örneğin, bir sıralama algoritması yapıyorsanız ve tüm test durumu başarısız olursa, algoritmanın her bir testi için sorunun gerçekte nerede olduğunu görmenize yardımcı olacak günlükler olmalıdır.

Evet, genel durumda kayıtlara ihtiyacınız var.

Günlüğe kaydetme hata ayıklama ile ilgili değildir. Peki, tamam, günlüğe kaydetmenin bir parçası bazen hata ayıklama ile ilgilidir ve geliştirme sırasında ihtiyaç duymuyorsanız bu bölümü atlayabilirsiniz.

Ancak günlüğe kaydetmenin daha önemli kısmı sürdürülebilirlikle ilgilidir. İyi tasarlanmış bir günlük kaydı aşağıdaki soruları cevaplayabilir:

• Uygulama hala hayatta ve tekmeliyor mu? (Her 1000 saniyede bir kalp atışı kaydederek.)
• Uygulamanın performansı son 10 ayda değişti mi? (Kullanım durumlarının performans istatistiklerini günlüğe kaydederek.)
• Başvurunun yükü son 10 ay boyunca değişti mi? (Her istek türü için istek sayısını kaydederek.)
• Arayüzlerimizden herhangi biri performans özelliklerini değiştirdi mi?
• Yeni sürüm, bazı alt sistemlere karşı farklı bir kullanım özelliği yaratıyor mu?
• DoS saldırısı altında mıyız ?
• Ne tür hatalar oluyor?

Bütün bunlar kayıt yaparak elde edilebilir. Ve evet, planlanmalı ve tasarlanmalı ve test edilmelidir, tercih edilen otomatik olmalıdır.

Günlük kaydı, tıpkı diğer özellikler gibi, tedaviyi hak eden bir özelliktir.

TL; DR: Günlüğe kaydetme ve TDD ortogonaldir. Birinin diğerine ihtiyaç duyması üzerinde hiçbir etkisi olmaması

TDD yapıyorsak giriş yapmamız gerekiyor mu? başarısız bir test uygulamada neyin yanlış olduğunu ortaya çıkarmaz?

Uyguladığım ve uyguladığım günlüğe kaydetme işlemlerinin çoğunda, geliştirme hata ayıklaması için değil (yardım edebilmesine rağmen) operasyonel sorun giderme çalışmaları yapıldı. Bu günlüğe kaydetmenin ana izleyici kitlesi, sunucularınızı yöneten yöneticiler ve op'lar, analiz için kendilerine gönderilen günlükleri destekleyen insanları ve günlüklere bakmak ve olanları araştırmak isteyen müşterilerdir.

Bu günlükler, büyük ölçüde entegrasyon noktalarına ilişkin sorunları gidermenize yardımcı olmak için vardır. Bu, ağ hizmetleri (veritabanı, sabun vb.), Yerel kaynaklar (disk, bellek vb.), Hatalı veriler (müşteri girişi, kötü / bozuk veri kaynakları, vb.) Vb. Olabilir (ayarlar, yapılandırmalar vb.) sorun gidermeye yardımcı olabilir.

Her sınıftaki her bir yöntemde günlük kaydı için test eklemeli miyiz?

Günlük kaydını test etmek için ihtiyaç duyduğunuz her yerde test ekleyin. Bilgileri kapatmak için özel aramalarınız varsa, o zaman test edilmelidirler. Yönelimli Programlama veya meta programlama kullanarak kayıt ve kayıt testi uygularsanız, bu testin yükünü azaltabilir.

Örneğin üretim ortamında bazı günlük seviyeleri devre dışı bırakılmışsa, bu testler ve çevre arasında bir bağımlılık getirmez mi?

Kodunuzu IoC kullanarak yazıyorsanız ve alaylardan yararlanıyorsanız, belirli bir çevre kurulumuna güvenmeden tüm kayıt işlemlerinizi etkin bir şekilde test edebilmelisiniz.

TDD genellikle kodlama hatalarını azaltmaya yardımcı olur. Spesifikasyondaki hatalarla veya işlerin nasıl yürüdüğü ile ilgili yanlış anlaşılmalar konusunda çok daha az yardımcı olur.

“Oh? Oturum açma işleminin başarılı olduğunu onaylamadan önce bir veri mesajı alabilirsiniz. Günlük kaydı, yazılımın ne yapmaya çalıştığını söylemek için çok kullanışlıdır, böylece yanlış yaptığınız şeyi tespit edebilirsiniz.

Tecrübelerime göre TDD yapmadığımız zaman uygulamaya büyük miktarda kayıt eklenir. Sonra belirsizlik seviyesi yükselir, bu yüzden neler olup bittiğini görmek için kayıt ekleriz.

Oysa TDD yaparken (ya da belki test yaparken) kendimi çok daha az log ifadesi ekleyerek buluyorum. Bu da daha az LOC anlamına gelir ve (her zaman değil) performansı etkileyebilir.

Ancak, çoğu durumda geliştirme yönteminden bağımsız olarak şirketimde işlevler için giriş çıkış günlüklerini yarı otomatik olarak ekliyoruz. Bildiğim kadarıyla bu üretim sorun analizi için zorunlu olarak kabul edildi.

Örnek, kamu arayüzünde mevcut olan bir EJB servis çekirdeğinin yöntemleri olabilir. Bir diğeri, bir fonksiyonun karmaşık hesaplamalar yaptığı bir durum olabilir. Yönteme giren rakamlara sahip olmak çok yardımcı olabilir (örneğin eldeki genel konuya geri dönmek için bir birim testi yazabilirsiniz).