Ekipte yeni biri olurken mevcut entegrasyon ve birim testlerinin kalitesi hakkında ne yapabilirsiniz?

Kariyerimde karşılaştığım yinelenen bir tema, bir takıma ulaşacak yeni geliştirici olmak ve mevcut birim ve entegrasyon test süitlerinde doğal bir güvensizliğe sahip olmak.

Görüşme sırasında size yönetim tarafından "birim testini şiddetle destekledikleri" ve açıkça teşvik ettikleri söylenir. Yaparlar, ama testlerin kendileri hakkında her şey yanlıştır. % 100 entegrasyon test kapsamı varken,% 10 tekrarlanabilir birim test kapsamı olduğunda% 100 teminat talep ettikleri gibi. Bulduğum diğer bazı problemler:

1. Birim testi nedir ve bir entegrasyon testi nedir arasında net bir gösterge yoktur. Ünite ve entegrasyon testleri aynı sınıfta karıştırılır.

2. Belirli bir ortamın veritabanındaki çok özel dinamik verilere açık bağımlılıklar bildirilen entegrasyon testleri.

3. İşlemsel olmayan entegrasyon testleri, temelde kendilerinin ardından temizlemeye zahmet edebilen veya ayırmayacak testler, bazen testi tekrarlanabilir hale getirmek için manuel veri tabanı "temizleme" gerektirir.

4. Ne olursa olsun hiçbir alaycı ve uygulama kodu sadece alay mümkün olması için büyük bir revizyon gerektirir. Başka bir deyişle, akılda test etmeden tasarım.

5. Test adına hızlıca bakmak ve hangi testlerin yapıldığını kabaca belirlemek için açık bir adlandırma kuralları yoktur.

Bunların hepsi TÜM testlerin işe yaramaz ya da kötü olduğunu söylememekle birlikte, bunların birçoğu oldukça iyi ve korunmaya değer, ancak bazen altın için pan yapmak gibi hissettiriyor. Sadece kara kutu test durumlarım için veritabanını mahvetmekten korktuğum için test yapmaktan kasten uzak durdum.

Bu aslında bana şahsen yazmadığım ya da bir şekilde gözden geçirmediğim içsel bir birim güvensizlik ve entegrasyon testlerini verdi. Test süitinizin kalitesine inancınız yoksa bir seviyede, o zaman takıma veya projeye hiçbir önemi yoktur.

Kendini bu durumda bulduğunda ne yaparsın? Böyle bir şeyle başa çıkmak için en iyi saldırı planının ne olacağını düşünüyorsunuz?

Tüm testler, sürümler arasında uzanan anıtsal bir çabayla yeniden düzenlenmeli mi? Bu eski projenin bir günlük sağlam birim test kapsamı olabileceği fikrinden vazgeçmeli mi?

Öncelikle, diğer afişlerin daha önce de yazdığı gibi, birim / entegrasyon testlerinin anlaşılmasından (teknik bir şekilde değil, ne yapması gerektiğini kastediyorum) ve yönetim tarafından zorlandığından mutlu olmalısınız.

Her şeyi yapmaya başlamadan önce, problemleri yönetime maruz bırakmalısınız, neden bir şeyler yapılmalı ve çok diplomatik bir şekilde, böylece dünyanın en iyi programcısı olduğunu düşünmüyorsunuz (öyle olsa bile! :-). Belki de başvurunun tamamen yeni bir şeyle değiştirileceğini söyleyeceklerdir ve öyleyse neden rahatsız etti. Belki de bunun iyi olacağını ve her sürümden önce test aşamasını hızlandıracağını anlayacaklardır. Ve takım arkadaşları ile diplomatik olmak ne olduğunu ve bir suçlu bakmak sadece hiçbir neden yoktur gibi neden milyonlarca sebep olabilir.

Daha iyi bir fikir onlarla konuşmaya çalışmaktır, böylece çabaya katılabilirler ve akıllı bir eşek olarak görünme şansınız daha az olacaktır, bu "ben" den daha "biz" olur.

Şimdi ne yapmak istediğinize öncelikler verin. Her zaman ilk önceliğinizin her zaman mevcut proje ödeviniz olacağını bilerek, işleri önceliklendirin ... Test probleminizde olduğu gibi, üç aşamada yapacağım şey:

1. Ünite ve entegrasyon testleri arasında nasıl fark yaratabilirim? Aşağıdaki çözümler geçerli olabilir ve münhasır değildir:

   • Refactor, test durumu yöntemlerinin adını (doğru davranışın nedeni, test vakasının test edilen sınıfla aynı adı paylaşmasıdır.
   • Biri "UnitTest", diğeri "IntegrationTest" adlı iki açıklama oluşturun. Bu ek açıklamalar sınıflarda ve yöntemlerde kullanılabilir. Bir sınıfın tamamı ünite veya entegrasyon testlerinden oluşuyorsa, sınıfı doğru açıklama ile işaretleyebilirsiniz. Değilse, her yöntemi doğru açıklama ile işaretleyebilirsiniz. Ayrıca, bu ek açıklamalar testleri başlatmadan önce fikstürleri dinamik olarak enjekte etmek için faydalı olabilir (faz 3)

2. Her entegrasyon testi için, her testin başında veritabanında olması beklenen "veri kümesi" nin ne olduğunu ve sonunda ne çıkarılması gerektiğini listeleyin (örneğin: tablo X, "id" ile bir kayıt gerektiriyor) "1" e, "isim" ise "foo", vb. Kaldırdığınız şeyin, başlangıçta sahip olduğunuzdan daha büyük / daha küçük olabileceğine dikkat edin; çünkü kodun kendisi, kalıcılık katmanına sırasıyla nesneler ekleyebilir / kaldırabilir. Muhtemelen hızlı bir şekilde, bu test durumlarının bir çoğunun aynı veri kümesine veya aynı veri kümesinin bir kısmına ihtiyaç duyduğunu fark edeceksiniz.

3. İlk iki aşama diğerleriyle karşılaştırıldığında nispeten hızlı bir şekilde yapılabilir. Artık veri kümenize sahip olduğunuzda, ihtiyacı olan her test durumu için veri kümesi fikstürleri kullanırsınız. Ama bu biraz zamana mal olacak ... Böylece bir tane yapabilir, size ne kadar zaman kalacağını görebilirsiniz ve her şeyi yapmak için ne kadar zamana ihtiyacınız olduğunu tahmin edebilirsiniz. Ayrıca, bu testi diğer meslektaşlarınıza ne yaptığınızı ve testler yapmak için belirli bir durumda bir veritabanına ihtiyacınız olmadığında neden bu kadar kolay olduğunu göstermek için kullanabilirsiniz.

Meslektaşlarınıza / yönetime nasıl yapılabileceğini hızlı bir şekilde göstermek istiyorsanız, 1., 2. ve 3. aşamaların tek bir sınav sınıfında yapılabileceğini not edebilirsiniz. Péter Török'in yazdığı gibi, takım arkadaşlarınıza "iyi yolu" hemen gösterebilmek ve böylece kötü kod üretmeyi bırakmaları yararlı olacaktır. Ancak, tüm test veri setini tanımlayan 2. fazın kalanının en iyi şekilde büyük bir adımda yapıldığını düşünüyorum.

Bunların arkasındaki API / teknolojiye gelince, konuyu biliyor gibisiniz.

Umarım bu biraz yardımcı oldu.

Not: Teklifim için, size ek açıklamaları bildiğim Java / C # kodunu ve AOP'un mümkün olduğunu düşünüyorum. Bunun diğer dillerde de mümkün olduğuna eminim ama bilmediğim bir şey hakkında yazmayacağım.

Tüm testleri birlikte düzeltemeyeceksiniz. Sana kelime odaklanmak gerektiğini düşünüyorum iyileştirme karşı revizyon . Ne geliştiriciler ne de geliştiriciler yönetimi elden geçirme konusunda hemfikir değildir, ancak projeyi olumsuz etkilemeden bir şeyleri iyileştirmenin bir yolu olduğunu gösterirseniz, dinleme olasılıkları daha yüksek olacaktır.

Öncelikle, kalite test kapsamınız olmadığı sürece mevcut kodu 'düzeltemezsiniz' veya yeniden düzenleyemezsiniz, bu yüzden önce test altyapınızı düzeltmeye odaklanacağım.

İyileştirilmesi gereken şeylerin bir listesini yapın ve onları önceliklendirmeye çalışın. Bağımsız ve tek tek testler yapabilme becerisi (birbirlerini etkilemiyorlar) ve ünite ayrılması ve entegrasyon testlerinin üzerinde çalışılacak ilk şeylerden bazıları olduğunu düşünüyorum. Sizin ve başkalarının sizin için doğru olanı yapmasını kolaylaştırmanız gerekir.

Uygulama kodu söz konusu olduğunda ... Uygulama mimarisinin tüm revizyonunu yapamazsınız, böylece daha iyi test edilmiş üniteler olabilir. Bunun yerine, yeni bir kod girdiğinizde, birim testini kolaylaştıran prensipler (bağımlılık enjeksiyonu gibi) uygulamaya çalışın. Bunun bir değişiklik için yeterince büyük olmadığını düşünebilirsiniz, ancak geliştiricilerin yararı görürse ne kadar hızlı yakaladıkları şaşırtıcıdır. Sadece daha iyisini yapmaya başlayan biri olmalı.

Takımınızla konuşun ve katılımlarını sağlayın. Yapabileceğiniz en önemli şeylerden biri, ' İzci Kuralı Kuralını ' takip etmek ve bir sınıftan ayrılmak veya daha iyi bir formda test etmek için küçük geliştirmeler yapmaktır . Tüm takım bu kuralı uygularsa işler daha hızlı iyileşir.

Bir süre sonra uygulamanın kötü durumda olan iyi ilkelerini ve alanlarını izleyen çok sayıda kodunuz olacaktır. Bu noktada, neyin iyi olduğuna dair bir temeliniz var ve takım eski miras işleri için daha büyük bir refaktör yapmanın faydası olup olmadığına karar verebilir veya olduğu gibi yaşayabilir.

Zaten önemli sayıda ünite / entegrasyon testine sahip oldukları bir projeye ulaşmak için nadir bir hediye olarak kabul edeceğimi kabul etmeliyim - hayatımda hiç bu kadar şansım olmamıştı. Hepsi gerektiği gibi çalışmasalar bile, halihazırda çok fazla çaba sarfedilmiş olsa da, ekip ve yönetim her zaman en iyi uygulamaları izlemese bile, yine de nedenini taahhüt etmişlerdir. Ünite testlerinin neden yazmaya değer olduğunu tartışarak zamanınızı harcamanıza gerek yok.

Ancak, tanımladığınız testler gerçekten de biraz iyileşme sağlayabilir. Ancak takım arkadaşlarınızla sorunları tartışırken tonunuza dikkat etmeniz gerekir . "Testlerin kendileri ile ilgili her şeyin sadece yanlış olduğunu " söyleyerek başlarsanız , ekibin geri kalanını yabancılaştırmanız çok çabuk olabilir. Bunun yerine, şu anki durumumun nasıl iyileştirileceğine odaklanmalısınız, ki - tekrar etmeliyim - şu ana kadarki deneyimime göre ortalamamdan hala daha iyi

IMO , ilk hedefiniz ekibin daha kötü testler üretmesini durdurmak olmalıdır . Bu yüzden, her özel gelişimin yararını ekip arkadaşlarınıza göstererek başlayın. Belli bir tekniğin faydasını görürlerse - dış bağımlılıkları kesmek, her testten sonra orijinal durumu geri yüklemek veya üniteyi ve entegrasyon testlerini ayırmak - bu uygulamaları uygulamaya başlayacaktır. Bu, kendi başına yavaş ama kesin bir şekilde uzun vadede test tabanının genel kalitesini iyileştirecektir (şimdi 1000 kötü test vakanız varsa ve ekip gelecek yıl 1000 iyi test üretiyorsa, kötü testlerin oranını düşürmüş olacaksınız) % 100 ila% 50). Bu güvence altına alındıktan sonra, mevcut testlere vaka bazında yeniden düzenlemeye karar verebilirsiniz. Yine, küçük iyileştirmeler zaman içinde büyük değişikliklere neden olacaktır.

Bir not olarak, gönderinizin tonundan, eskiden olduğum bir yerde olabileceğinizi düşünüyorum: başkaları tarafından yapılan işlere güvenmemek, işlerini yapmaktan korktuğu için kimseye görev verememek kendi kalite standartları. Tecrübelerime göre burası iyi bir yer değil, çünkü uzun vadede kolayca kişisel çatışmalara ve tükenmeye yol açabilir. Her şeyi yalnız yapamazsınız, ekibin geri kalanıyla birlikte çalışmalısınız. Sadece birlikte başarabilirsiniz.

Test bağımsızlığı için çalışın. Eğer X testi, test veritabanını Y testi başarısız olacak şekilde değiştirirse, test Y'yi değiştirin. Bu küçük senaryoda odaklanılacak şey, X'in veritabanını karıştırdığı değil, Y'nin uygun olmayan bağımlılıkları olduğu. Bu bağımlılıkları kaldırın (veritabanını saplayarak, testi yeniden yapılandırarak veya veritabanını Y'nin geçeceği bir duruma başlatarak) ve şimdi bir tane daha bağımsız çalışma testine sahipsiniz. Bu ilerleme (tartışmalı olarak, "veritabanını karıştırmamak için" X "düzeltilmesi olmazdı).

Yarattığınız karmaşaya rağmen, birlikte çalıştığınız milletten, olabildiğince iyi ve saygılı olun. Her şeye rağmen doğru şeyi yapmaya çalışıyorlar; bunu aklınızda bulundurun ve yapmalarına yardımcı olun.

Takımda yeni olmanın iyi yanı, şeylere "taze" bir yaklaşımın olmasıdır. Kötü olan kısmı, başkalarının size inanmakta zorlanmaları olabilir.

Yapılması gerekenlerin bir listesini çamaşır yıkama yapmayın. Ancak acil görünen ve başkalarının yanıt verme ve çözüm önerme olasılığı yüksek olan BİR şeyi seçin. İşe yararsa, harika, o zaman ilk başarınızın gücüyle başka bir soruna başka bir çözüm önerin.

Ancak, yavaşça tek tek yavaşlayın ve yeni grup arasında fikirlerinizi yavaşça "yakalayacağınızı" umalım.

görmek istediğiniz örneği ayarlayın, ancak bir testteki başka bir geliştiricinin bakış açısını takdir edin: bir geliştirici başarılar için test edebilir, bir diğeri başarısızlıklar için test edebilirken, bir geliştirici sınıfı yazarken, bir diğeri testi yazarken ilk kez kullanmış olabilir.

Mevcut testlerin (erm, çoğu) hala bir amacı olmasa da, hala bir amacı vardır. her şeyi bir kerede elden geçirmeyi ve yeniden düzenlemeyi önermiyorum (sıkıcı ve hataya açık). kötü testlerin nihayetinde güncellenmesi, yeniden yazılması veya yazılım geliştikçe eski hale gelmeleri gerekir.

Teste yaklaşımınız bazı yönlerden üstündeyse, insanlar bu modelden öğrenecek veya sizden yardım isteyeceklerdir. Kaynaklar arasında bir denge olacak, ancak testlerinizi desteklemek için gerektiği kadar uzatabilirsiniz.

Sonuç olarak, testler yoluyla programların kalitesini artırmak ve kapsamı iyileştirmek istiyorsunuz. Bunu test etmeye ve iyi bir örnek belirlemeye daha fazla önem vererek yapabilirsiniz - ancak diğerlerinin bakış açılarını takdir edin.

önemi vurguladığınızda, testlerinizin çalışma ortamını farklı kılabilirsiniz - açık bir örnek, testleri paralel olarak gerçekleştirmektir; Reentrant değilse, programınıza veya testinize bir hata yerleştirdiniz (kazan / kazan). Daha sıkı bir test ortamı, kötü testlerin düzeltilmesini ve / veya yeniden yazılmasını zorlar (umarım ikinci kez doğru yoldur). yavaş yavaş bu tür değişiklikleri uygulayın (bir seferde testlerin yarısını kesmeyin - bu gerçek bir sorundur), onları neyin iyi bir test yapıp yapmadığını ve nihayetinde iyi bir program öğrenmelerini sağlayın. o zaman siz ve diğeri girip testleri / onarımı / genişletmeyi yaptığınızda, öğrendiklerinizi uygulayın - bu artımlıdır ve o andaki bağlam / programı daha iyi anlarsınız.

Zamanla onları düzelt

Aynı durumdayım. Sadece her sabah bir saatimi testlerden geçerek ve düzeltilinceye kadar onlardan geçirdim. Orta büyüklükte bir kod temeli idi ve sanırım 1,5 ay içinde bitirdim. Ayrıca testlerimizde kendime daha fazla güvenmiştim.

Testin iyi bir test olduğu sürece, bir testin bir test veya entegrasyon testi olup olmadığını kişisel olarak umursamıyorum. İyi bir testle şunu kastediyorum:

• sonra kendini temizler
• tekrarlanabilir
• çevresel etkileşimleri en aza indirir
• tutarlıdır

Yol boyunca daha iyi bir test inşaatı yaptım (yani insanları çok rahatsız ettim).