Agile metodolojilerini uygulamaya çalışan çok sayıda takımdayım ve bu takımlar test merkezlidir. Test, Çevik metodolojiyi uygulamanın gerekli bir parçası mı yoksa yıllar boyunca süren bir XP uygulaması mı?

Test, çeviklik açısından kesinlikle esastır, çünkü çevik artan artışlara dayanır: Zorluk şu anki değişikliklerin eski kodunuzu nasıl etkileyeceğini görmek zor olabilir. Bir şeyi bozmadığınıza emin olmanın en iyi yolu, onu test etmek ve NASIL test etmeyi bilmek. Bu şekilde, hatayı hemen bulursunuz, yolun aşağısında değil, bazı eski özelliklerin kodunu yazarken tam olarak ne yaptığınızı unutuyorsunuz.

Bunun daha geleneksel, yukarıdan aşağıya tasarım tipi programlamasından farklı olmasının nedeni, bu ortamda, a) bitmiş ürüne sahip olana kadar test etmeniz çok zordur b) teoride, tüm tasarım kriterlerini aynı anda göz önünde bulunduruyorsunuz ve bu nedenle önceki tasarım kararlarını kıran bir tasarım kararı verme olasılığınız azalır.

Muhtemelen otomatik testlerden, birim testlerinden, entegrasyon testlerinden vb. Bahsediyorsunuz. Bunlar manuel testlerden daha hızlıdırlar (test yapanlar ve benzeri) çünkü çok yavaşlar, bu nedenle yaptığınız her küçük değişikliği test etmek mümkün değildir. Çevik küçük hızlı yinelemeler nedeniyle, saatler veya günler yerine saniyeler veya dakikalar içerisinde doğruluğu doğrulayan testlere sahip olmak çok yararlıdır.

Eğer testleriniz yoksa, kodunuzun çalıştığını nereden biliyorsunuz?

Düzenleme: Testlerin kodun çalıştığını ispatlayamadığı iddiası tek bir önemli terimi, yani işe yaramazsa tanımlamayı başaramaz . Bir programın çalışması için ne anlama geliyor? Bu terim belirsiz kalırsa, herhangi bir programın çalıştığını kanıtlamak veya emin olmak için hiçbir yolu yoktur. Hiç.

Öte yandan, eserleri "şartnameye göre davranmak" olarak tanımlayabilirsiniz . Artık yalnızca kodun çalıştığını göstermek için testleri kullanamazsınız, ancak testlerin kendileri de kodunuzun davranışının çalıştırılabilir bir belirtimi olarak işlev görebilir. Başka bir deyişle, iyi yazılmış bir test takımı, çalışmanın ne anlama geldiğini tanımlar .

Bu düşünce tarzı, sizi bir hatanın anlamını yeniden incelemeye zorlar . Kodunuz tüm testleri geçerse, kodda hiçbir hata yoktur. Buna rağmen, sistem olması gerektiği gibi davranmazsa, davranışı doğru bir şekilde belirtilmez. I. e. Hata testlerde tanımlanmış olan özelliktedir.

Yazılım geliştirmeye yönelik bu yaklaşım, bir sistemin işlevsel spesifikasyonunu, dünyadaki her yazılım mühendisliği kitabına göre, çok iyi bir şey olan uygulamasından ayrıştırmaktadır. Aynı zamanda, bu yaklaşım uygulamanızın her zaman işlevsel özelliklere karşılık gelmesini sağlar.

Hayır, gerekli değil"

Çevik ilkeleri hiçbir şey söylemek doğrudan testi hakkında.

Ama Çok Tavsiye Edilir

Agile'nin sürdürülebilir bir sürece bağlılığı, sürekli / artan teslimat ve yazılım kalitesi göz önüne alındığında, otomatik test şu anda çoğu proje için mevcut en iyi çözümdür

İstisnalar (Jörg W Mittag tarafından belirtildiği gibi), kesinlikle doğru geliştirme araçlarını, kod üreten meta-programlama sistemlerini, vb. Ancak bu tür sistemler nadirdir.

Hem Çevik hem de XP, Büyük Tasarım Yukarı Önden kaçınmaya çalışır . BDUF'da şartlar toplanır, resmi bir şartname yaratılır, sonra kodlama yapılır, sonra test yapılır. Bu, tıbbi ekipman, uzay sondaları vb. Gibi iyi tanımlanmış, görev ve hayati öneme sahip sistemler için anlamlıdır.

O sorunlar için iyi çalışmaması nedeniyle Çevik Bu akışı önler değildir "müşteri bu hafta için sorar değiştirir ne olursa olsun" örneğin, iyi tanımlanmış. Hala resmi bir şartnameye ihtiyacımız var, bu yüzden ne yapacağımızı ve ne zaman yapıldığımızı biliyoruz, ancak bir tür yazılı belge yerine kodları otomatik testler biçiminde kullanıyoruz .

Otomatik ünite testleri yazmak hızlı, çalıştırması kolay ve çok modüler / ayrıştırılmış. Bu, gereksinimleri resmi olarak belirlemek ve kontrol etmek için onları hızlı bir yol yapar.