Bir test antik kültüründe teste nasıl başlayabilirim? [kapalı]

Bir itirafta bulunacağım: Resmi otomatik test hiçbir zaman programlama geçmişimin bir parçası değildi. Şu anda birçok geliştiriciyle (çoğu bir tür web geliştiricisi) çok büyük bir şirkette çalışıyorum ve çoğunun da test etmediği açıktır *. (* Resmi olarak söylemeye devam etmeyeceğim ; lütfen çıkarımda bulunun.)

Teste başlamak için kuruluşumun desteğini almayı beklersem, bu asla olmayacak. Yönetimde testi zorlayarak "içeriden bir şeyler değiştirmeye" çalışırsam, değişiklik gerçekleşmeden önce buharım tükenir. Şimdi teste başlamam gerekiyor.

Ama TDD ve ilkiyle birlikte üretim kodu ile birlikte birçok test kodu ile sonuçlanacağım. Sürüm kontrol sistemlerimiz (tümü merkezileştirilmiş) test kodunu saklamak için organize edilmemiştir. İş istasyonumdaki her şeye bir yer bulmam gerekecek.

Değer vermeyen veya araçları sağlamayan bir kültürde kişisel yazılım testi uygulamasına başlamak mümkün müdür? Resmi araç ve kuruluşların testler, çerçeveler ve otomasyonlar için yeri olmadığında test etmenizi sağlamak için hangi teknikleri ve araçları kullanıyorsunuz?

Ben şahsen bunu büyük bir başarı ile yaptım. Başarı için anahtar faktörler:

• (Geçici) yönetim desteği alın. Otomat testlerinin avantajları iyi belgelenmiştir ve herhangi bir menajeri en azından denemeye ikna etmelidir. Bu, VCS ve bir yapı sunucusunda bir nokta bulmayı içerir, çünkü
• Otomatik testler, yalnızca sık sık ve otomatik olarak çalıştırıldıklarında tam değerlerini sağlar, böylece sorunları yakında öğrenirsiniz ve bunları çalıştırmayı unutmayan insanlara güvenmek zorunda kalmazsınız. Bunları en az günlük çalıştıran bir yapı sunucusuna ihtiyacınız var. Bu eski bir iş istasyonu olabilir. Jenkins koşmak için çok az iş gerektirir.
• Örnek olun. Testler yazın, size sağladığı yararlar hakkında konuşun ve diğer geliştiricilerin getirdiği hataları ortaya çıkardıklarında, potansiyel olarak çok daha büyük utanmadan nasıl korundukları hakkında konuşun.
• Düşük asılı meyveyi tercih edin. Uygulamanın bazı bölümlerini test etmek zor, diğerleri ise kolay olacaktır. Bazıları sağlam, bazıları kırılgan olacaktır. Kırılgan ancak test edilmesi kolay parçalar için yazma testleri en kısa sürede en yüksek değeri sağlar.
• Yeniden kullanılabilir testler yazıp yazamayacağınıza bakın, örneğin tüm modüllerin (web sayfaları, REST hizmetleri, her ne olursa olsun) sahip olması gereken, ancak genellikle unutulan test kuralları veya özellikleri.

Yönetim desteği olmadan suda ölürsünüz. Yönetim, değerli işler yapmadığınızı iddia edecek, incelemelerinizde cezalandırılacaksınız ve sonunda kovulacaksınız. Yönetimi erken test etmenin daha az maliyete mal olduğunu görmenin yolları vardır. Kültürü değiştirmek mümkündür ama boynunuzu doğrama bloğuna koyuyorsunuz.

Machiavelli Prens bölümünü, herhangi bir şey yapmadan önce değişimi nasıl tanıtacağınızı okumanızı öneririm .

Benim deneyimime göre, kültür anti-test ise, bunu makul bir şekilde tanıtamazsınız. Testler zaman kaybı olarak görülecektir ve "zaman kaybetmek" ya da "çok uzun sürmek" için kınanacaksınız ya da kod yıllarca test edilebilir bir şekilde yazılmama (yani arayüz yok, her şey) testleri ilk etapta yazabilmeniz için yeniden test etmek ve / veya yeniden yazmak için çok fazla zaman harcamanız gerekir (böylece "çok uzun süre" ve "zaman kaybetme" riski taşır). .

Yalnızca mevcut şeylerle etkileşime girmesi gereken (kötü alanların etrafında güzel bir paketleyici oluşturun) yeşil alan işleri yapıyorsanız veya sorunlara neden olmayacağı veya yapmanızı gerektirmeyen küçük miktarlarda yapabiliyorsanız bir şansınız olabilir. "size atanmamış görevler üzerinde çalışmak" hangi köpek kulübesine koyabilirsiniz.

Otomatik testin ele alabileceği bir sorun (şu anda tanınmayan) yeterince iyi bir durum ortaya çıkana kadar çok ileri gideceğinizi sanmıyorum.

Tanımlanmış komut dosyalarına karşı el ile test kültürü varsa, bu komut dosyalarının yürütülmesinin, eksik veya yanlış sonuç alma riski ile birlikte maliyeti vardır. Bunun bir tarihi (belgelenmiş veya "savaş hikayesi" formunda) olabilir. Uzun vadeli maliyet tasarrufu sağlamak amacıyla bu manuel testlerden bazılarını otomatikleştirmek için bir pilot proje önerin.

Manuel bir test fonksiyonu bile yoksa, o zaman işin otomatik veya başka türlü herhangi bir resmi testin değere sahip olduğunu algılamadığını öneririm. Bu durumda, önündeki yolun uzun ve dik bir yokuş yukarı olduğunu düşünürdüm, ancak yine de işletmenin yazılım kalitesine daha az rahat bir yaklaşım benimsemekten fayda sağlayabileceğine dair açık bir gösterime ihtiyaç duyuyorum. Bunu yapamıyorsanız, o zaman ticari gerekçelerle bu fikre nasıl destek olabileceğini görmek zor.

Bir fikir, başka birinin yazdığı kodun hatalı olduğunu kanıtlayan bir test yazmayı hedeflemenizdir. Kavramı satmalı.