Bunu yapmayan bir şirkette birim testi uygulama

Şirketimin yazılım geliştirme başkanı yeni "istifa etti" (yani işten çıkarıldı) ve şimdi şirketimizdeki geliştirme uygulamalarını geliştirmeye çalışıyoruz. Buradan oluşturulan tüm yazılımlarda birim testi uygulamak istiyoruz.

Geliştiricilerin geribildirimi şudur:

• Testin değerli olduğunu biliyoruz
• Ancak, özellikleri her zaman değiştirirsiniz, bu yüzden zaman kaybı olur
• Ve son teslim tarihleriniz o kadar sıkı ki, test etmek için yeterli zamanımız yok

CEO'dan geri bildirim:

• Şirketimizin otomatik test yaptırmasını istiyorum, ancak nasıl yapılacağını bilmiyorum
• Büyük şartname belgelerini yazmak için zamanımız yok

Geliştiriciler şimdi özellikleri nasıl elde ediyor? Sözlü veya PowerPoint slayt. Açıkçası, bu büyük bir problem. Benim önerim şudur:

• Ayrıca geliştiricilere bir dizi test verisi ve birim testi verelim
• Bu özellik. Ne istediğine dair net ve nicel olmak yönetimin sorumluluğundadır.
• Geliştiriciler, ihtiyaç duydukları diğer işlevsellikleri koyabilirler ve testlerle kapsanmaları gerekmez.

Peki, bu durumda olan bir şirkette bulunduysanız, sorunu nasıl çözdünüz? Bu yaklaşım makul görünüyor mu?

İki tür testi karıştırdığınız anlaşılıyor : birim testleri ve sistem / kabul testleri . Birincisi, daha düşük bir seviyede çalışır ve genellikle programın derinliklerinde bulunan ve doğrudan kullanıcılar tarafından görülmeyen küçük kod parçalarını (genellikle bireysel yöntemler) test eder. İkincisi, tüm programı kullanıcıları tarafından görüldüğü gibi, çok daha yüksek bir ayrıntı düzeyinde test eder. Böylece, sadece ikincisi herhangi bir sistem spesifikasyonu formuna dayanabilir.

İki konunun ayrılması, gelişmiş bir geliştirme sürecine doğru ilerlemeye başlamayı kolaylaştırır . Yazılımın yüksek düzeyde nasıl belirtildiğinden (belirtilmediğinden) bağımsız olarak birim testlerini yazmaya başlayın . Bir geliştirici bir yöntem oluşturduğunda veya değiştirdiğinde, birim test edilebilen (ve yapılması gereken) somut bir şey yapar. Deneyimlerime göre, yüksek düzey gereksinimlerin değiştirilmesi bile bu alt düzey kod bloklarını önemli ölçüde etkilemez: kodun atılmak veya tamamen yeniden yazmak yerine çoğunlukla yeniden düzenlenmesi gerekir. Sonuç olarak, mevcut birim testlerinin çoğu iyi çalışmaya devam edecektir.

Birim testini etkinleştirmek için önemli bir koşul: son tarihler yönetim tarafından önceden kararlaştırılmamalı, bunun yerine geliştiriciler tarafından yapılan iş tahminlerine dayanmalıdır (bu da tahminlerine uygun birim testlerini yazmak için gereken süreyi içermelidir). Veya, eğer son teslim tarihi sabit ise, teslimat kapsamı tartışılabilir olmalıdır. Hiçbir miktarda (yanlış) yönetim, belirli sayıda geliştiricinin belirli bir sürede yalnızca belirli miktarda kaliteli iş sunabileceği temel gerçeğini değiştiremez.

Buna paralel olarak, gereksinimleri açıklığa kavuşturmanın ve belgelemenin en iyi yolunu tartışmaya başlayın ve bunları üst düzey kabul testlerine dönüştürün. Bu, bir kuruluşun tamamında daha iyi ve istikrarlı bir duruma gelmek için yıllar alabilen daha uzun bir ardışık arıtma sürecidir. Açıklamanızdan oldukça emin olan bir şey var: büyük şartname belgelerini önceden yazarak sürekli değişen gereksinimleri düzeltmeye çalışmak işe yaramayacak . Bunun yerine, daha çevik bir yaklaşıma geçilmesi tavsiye edilir, kullanıcılara sık yazılım sürümleri ve gösterileri ve gerçekte ne istedikleri hakkında birçok tartışma ile. Kullanıcı gereksinimlerle ilgili fikrini istediği zaman değiştirme hakkına sahiptir - ancak her değişikliğin maliyeti vardır (zaman ve para olarak). Geliştiriciler, her değişiklik isteğinin maliyetini tahmin edebilir ve bu da kullanıcı / ürün sahibinin bilinçli kararlar vermesini sağlar. "Şüphesiz, bu özellik değişikliği iyi olurdu ... ama bu diğer önemli özelliğin piyasaya sürülmesini geciktirirse ve bu kadar pahalıysa, şimdilik şimdilik biriktirmeye koyalım".

Kullanıcıların kabul test senaryolarını tanımlamaları ve test verileri oluşturmalarını sağlamak, onları daha fazla dahil etmenin ve kullanıcılar ile geliştiriciler arasında karşılıklı güven oluşturmanın harika bir yoludur. Bu, her iki tarafı da somut, ölçülebilir, test edilebilir kabul kriterlerine odaklanmaya ve kullanım durumlarını tipik olandan çok daha ayrıntılı olarak düşünmeye zorlar. Sonuç olarak, kullanıcılar her sürümde mevcut geliştirme durumunu ilk elden kontrol ederler ve geliştiriciler projenin durumu hakkında daha somut, somut ölçüm geribildirimi alırlar. Ancak bunun kullanıcılardan daha fazla bağlılık ve kabul edilmesi ve öğrenmesi zor olabilecek yeni çalışma biçimleri gerektirdiğini unutmayın.

Geçiş yapma deneyimim

Uzun yıllar boyunca, kodum için birim testleri yazmak için yeterli zamanım olmadığı için yanlış anlama altındaydım. Testler yazarken şişkin, ağır şeyler vardı, bu da beni sadece ihtiyaç duyduklarını bildiğimde birim testleri yazmam gerektiğini düşünmeye teşvik etti .

Son zamanlarda Test Odaklı Geliştirme'yi kullanmaya teşvik edildim ve bunun tam bir vahiy olduğunu gördüm. Şimdi, birim testleri yazmak için zamanım olmadığına kesin olarak inanıyorum .

Deneyimlerime göre, testler göz önünde bulundurularak geliştirerek daha temiz arayüzler, daha odaklanmış sınıflar ve modüller ve genellikle daha fazla SOLID , test edilebilir kod elde edersiniz .

Birim testleri olmayan ve bir şeyi manuel olarak test etmek zorunda kalan eski kodlarla çalıştığımda, "bu kod zaten birim testleri varsa bu çok daha hızlı olurdu" diye düşünmeye devam ediyorum. Her ne zaman yüksek kuplaj ile kodlamak için birim test işlevselliği eklemek zorunda kalsam, "bu bir de-coupled bir şekilde yazılmış olsaydı çok daha kolay olurdu" diye düşünmeye devam ediyorum.

Desteklediğim iki deney istasyonunun karşılaştırılması ve karşılaştırılması. Biri bir süredir varlığını sürdürüyor ve büyük miktarda eski kod içeriyor, diğeri nispeten yeni.

Eski laboratuvara işlevsellik eklerken, genellikle laboratuvara inmek ve ihtiyaç duydukları işlevselliklerin sonuçları ve bu işlevselliği diğer işlevleri etkilemeden nasıl ekleyebileceğim ile çalışmak için saatler geçirmektir. Kod, çevrimdışı testlere izin verecek şekilde ayarlanmamıştır, bu yüzden hemen hemen her şeyin çevrimiçi olarak geliştirilmesi gerekir. Çevrimdışı geliştirmeye çalışsaydım, makul olmayacak kadar sahte nesnelerle sonuçlanırdım .

Daha yeni laboratuvarda, genellikle masamda çevrimdışı olarak geliştirerek, yalnızca hemen gerekli olan şeyleri alay ederek ve daha sonra laboratuarda sadece kısa bir süre geçirerek, alınmayan kalan sorunları ütülerek işlevsellik ekleyebilirim. -hat.

Benim tavsiyem

İyi başladınız, geliştirme iş akışınızda büyük değişiklikler yapacağınız zaman, herkesin bu kararı vermekle meşgul olduğundan ve ideal olarak çoğu insanın satın aldığından emin olmalısınız . Sorunuzdan, bu hakkın var gibi görünüyor. Eğer insanlar bu fikre hevesli değilse, ya başarısızlığa ya da kötü niyet yaratmaya mahkumdur.

Eğer zorlayıcı bir iş örneği sunabilirim sürece, olur değil senin bütün sistem için birim testler ve şartnamelerin bir zemin yukarı uygulanmasını öneriyoruz. Yukarıda bahsettiğim gibi, eğer bir sistem test düşünülerek tasarlanmamışsa , bunun için otomatik testler yazmak çok zor olabilir.

Bunun yerine küçük başlamayı ve İzci Kuralını kullanmanızı tavsiye ederim :

Kamp alanını her zaman bulduğunuzdan daha temiz bırakın.

Bu kod tabanında bir şey uygularken, mevcut davranışı test etmek ve eski davranıştan yeniye geçişi test etmek için gereken belirli testleri belirleyebilirseniz, hem spesifikasyondaki değişikliği belgelediniz hem de Sisteminiz.

Dokunmadığınız modüller birim testleri almaz, ancak bunlara dokunmuyorsanız, muhtemelen kullanımda kapsamlı bir şekilde test edildikleri ve herhangi bir değişikliğe ihtiyaç duymadıkları veya asla kullanılmadıkları içindir.

Bundan kaçınmak istediğiniz şey, asla ihtiyaç duyulmayacak geliştirici çabası testleri yazmaktır ( YAGNI aynı zamanda üretim kodu * 8 'için olduğu gibi test kodu için de çalışır), bir daha asla kullanılmayacak ve insanları demoralize etmeyecektir. sonuçta testlerin işe yaramaz olduğunu düşünerek.

özet

Küçük başlayın, testlere aşamalı olarak güvenin ve ekibinize en çok ne zaman ve nerede yarar sağladıklarını test ederek iş değeri kazanın.

Yapılacak ilk şey teste değil, genel süreci doğru yapmaya odaklanmaktır. Ne yapması gerektiğini tam olarak anlamadıysanız hiçbir şeyi test etmeye gerek yok!

Yani .. önce özellikleri ve değişmeyen belgelenmiş özellikleri (hemen değil). Bunları halletmeye bakmalısın. Kullanıcıların teknik özellikleri yükleyebileceği veya doğrudan yazabileceği bir web sitesi öneriyorum. Bunu bir hata izleyiciye ve projenin ilerleyişine ilişkin bir kılavuza da bağlayabilirsiniz.

Şansınız, gerçekten ihtiyacınız olan bu. Buna dahili olarak birim testi ekleyebilirsiniz ve yönetimin asla geliştiricilerin birim testleri yaptığını bilmesine gerek yoktur. Bir bakıma böyle olması gerekiyordu.

Yine de sistem testi yapmanız gerekecek, ancak bu proje yönetimi web sitesine de bağlanabilir, bir kez yayınlandıktan sonra, test ekibi (rotasyonda başka bir şanslı geliştirici olsa bile) bunu görmek için kullandıkları testlerle güncelleyebilir her şey birlikte takılıyor.

Dürüst olmak gerekirse, bunun bir gecede değişeceğini düşünmüyorum, eğer 'ağızdan ağıza' özellikleri almaya alışkınsanız, savaş neredeyse tamamen bu davranışı değiştirecek - ve buna karşı direnç kazanacaksınız. "Sadece x yap" diyen ve şimdi hepsini yazması gereken bir kullanıcı (veya BA veya PM veya her kim) iyi yanıt vermeyecek, belirsiz spesifik belgeler yazıp daha sonra bunları netleştirecek olmaları kulaktan kulağa güncelleme ile. Bu yüzden birim testini unutun ve geliştirme yaşam döngüsüyle ilgili büyük soruna başlayın.

İlk sorun: "geliştiricilere bir dizi test verisi ve birim testi" vermek için, öncelikle geliştiricilerin işi olan bu birim testlerini yazmanız gerekir. Birim testleri de spesifikasyonun yerini almaz: spesifikasyonun birim testlerden daha yüksek bir soyutlama seviyesine sahip olması amaçlanmıştır.

İkinci sorun: Görünüşe göre, maksimum birim testi kapsamı istiyorsunuz. Bu durumda, evet, gereksinimlerin sürekli değiştiği bir bağlamda hem testleri hem de kodu yazmak çok zaman ve paraya mal olacaktır. Bunun yerine, kodun hangi bölümlerinin kritik olduğuna karar verin ve birim yalnızca bu bölümleri test eder. Çoğu durumda, değişen gereksinimler ürünün kritik parçalarını etkilemez. Bir müşteri (veya CEO veya her ne olursa olsun) genellikle bu paneli sağa taşımayı veya bu başlığın rengini kırmızıdan yeşile değiştirmeyi ister: kimsenin umursamadığı ve yoğun test gerektirmeyen şeyler. Öte yandan, bir müşteri hiçbir zaman karma algoritmayı SHA512'den SHA256'ya değiştirmeyi veya oturumları saklama şeklinizi değiştirmeyi istemezken, en fazla test gerektiren kısımlardır.