Geliştiriciler, birim testleri dışındaki testlerden sorumlu olmalı mı, eğer hangisi daha yaygınsa?

Şu anda oldukça büyük bir proje üzerinde çalışıyorum ve JUnit ve EasyMock'ı oldukça kapsamlı bir şekilde birim test işlevselliği için kullandım. Şimdi başka hangi tür testlerden endişe etmem gerektiğiyle ilgileniyorum. Bir geliştirici olarak, işlevsel ya da regresyon testi gibi şeyler için endişelenmek benim sorumluluğum mu? Maven / Ant / Gradle gibi araçlara bunları kullanışlı bir şekilde entegre etmenin iyi bir yolu var mı? Bunlar bir Test Cihazı veya BA için daha uygun mudur? Kaçırdığım başka faydalı testler var mı?

Kusursuz kod göndermeye çalışmak sizin sorumluluğunuzdadır. Gönderdiğiniz koda güven duymak için yazmalı, yardım yazmalı veya testlerin yazılmasını veya yapılmasını sağlamalısınız.

Not: Kusursuz kod vermeniz gerektiğini söylemiyorum. Aksine, size verilen gereksinimler için bulabileceğiniz en iyi kodu yazmaya çalışmalısınız. Bunu yapabilmenin bir kısmı, kodun test edilmesi gerektiği anlamına gelir.

Bunun, işlevsel ve regresyon testlerinden şahsen sorumlu olduğunuz anlamına gelip gelmediği, çoğunlukla şirketinizin nasıl örgütlendiğinin bir işlevidir. Tanıdığım en yüksek vasıflı programcıların hepsi "X tipi testler yazmak benim sorumluluğum mu?" Diye sormuyorlar. Bunun yerine kendilerine "kodumun doğru bir şekilde test edildiğinden emin olmak için ne yapmalıyım?" Diye soruyorlar. Cevap, birim testleri yazmak veya regresyona testler eklemek olabilir veya bir KG uzmanıyla konuşmak ve hangi testlerin yazılması gerektiğini anlamalarına yardımcı olabilir. Bununla birlikte, her durumda, doğru bir şekilde test edildiğinden emin olmak için yazdıkları kod hakkında yeterince özen gösterdikleri anlamına gelir.

Alt satır: yüksek kalitede kod sağlamaktan sorumlu olmalısınız. Bu, bazı fonksiyonel veya regresyon testleri yazmanız gerektiği anlamına gelirse, yapın.

Bu size yardımcı olabilir:

S1 geliştiriciler tarafından yazılmıştır.

S2 geliştiriciler tarafından otomatikleştirilir ve işletme ve / veya test uzmanları ile birlikte yazılır.

Kaçırdığım başka faydalı testler var mı?

Gherkin dilini kullanan BDD tarzı çerçeveler önerdiğim kabul testleri var : JBehave (Java), Salatalık (Ruby), Behat (PHP), vb. Bu tür testlerin birim testlerine göre bazı avantajları vardır:

• Testler geliştiriciler tarafından kolayca okunabilir, bu yüzden müşterilere gösterebilirsiniz
• Testler, uygulama ayrıntılarına girmeden iş süreçlerini açıkça tanımlamaktadır (Ben uygulamanın önemli olmadığını kastetmiyorum - kesindir - ancak iş gereksinimlerini kodun kendisinden ayırdığınızda daha iyidir)
• Testler, kullanıcıların uygulamanızı kullanarak yapacakları işlemleri yapar
• Yazmaları daha kolay (IMHO, dile ve çerçeveye bağlı olabilir): alaycı değil, daha az teknik detay

İşlevsel test, tıpkı testler gibi otomatikleştirilebilir ve projenizin farklı bileşenlerinin birlikte nasıl çalıştığını ve sisteminizin iş kurallarını ne kadar iyi yansıttığını test etmek için çok kullanışlıdır.

Ayrıca, bu otomatik test, yazılıma yapacağınız tüm önemli (veya küçük) değişiklikler için (hata düzeltme, refaktör, işletme değişikliği, yeni işlevsellik, vb.) Regresyon ve kabul testi paketi görevi görür. Bu, geliştiricilere bunu yapma konusunda daha fazla güven verir.

Bu tür testler için çeşitli çerçeveler var, çok iyi sonuçlar veren fitnes kullanıyoruz . Web sayfalarını test etmek için çok iyi bir kütüphaneye sahiptir (web uygulamamızı ve web hizmetlerimizi test etmek için kullanıyoruz) ve Maven ve Jenkins ile çok iyi bütünleşiyor .

Ayrıca, geliştiriciler arasında "çapraz fonksiyonel test" yapmak için kullanılır, ancak bu tür bir test "tekrarlanabilir" değildir, bu yüzden faydası sınırlıdır ...

Bir geliştirici olarak, tüm kodumu birim testinden sorumlu olduğumu düşünüyorum ve kusurlu olma ihtimallerimin en iyisini garanti ediyorum. Bu nedenle, alay etme gibi elimizde çok fazla araç var. Testlerinizde alaycı nesneler yaratmanın amacı, kodunuzu "dış" dünyadan tamamen uzak tutmaya çalışın ve iyi çalıştığını ve başarısız bir şey varsa "sizin suçunuz değil" olduğunu garanti etmektir.

Bu sizin suçunuz olmadığı ve kodunuzun olması gerektiği gibi çalıştığı gerçeğine rağmen, bu testlerin geri kalanında yardımcı olamayacağınız anlamına gelmiyor. Çalışmalarınızı, başkaları tarafından yapılan çalışmalara entegre etmenin sizin sorumluluğunuzda olduğuna inanıyorum. BT Geliştirme ekipleri her zaman iyi yağlanmış bir makine olarak çalışmalı, güvenilir yazılımlar sağlamak için diğer bölümlerle (QA gibi) daha büyük bir ekip olarak çalışmalıdır.

Ama bu bir takımın işi, sadece senin değil.

Açıkçası entegrasyon testleri ; ünite testlerinden daha önemli ve yazmak daha zordur. Bir ev inşa etmek gibidir; ünite testlerinde, yalnızca tuğlaların sağlam olduğu ve basınç, sıcaklık, nem ve diğer koşullara dayandığı garanti edilir. Ancak, evin bir araya getirilmiş tuğlalarla nasıl göründüğü ve nasıl davrandığı hakkında hiçbir fikriniz yok.

Büyük projelerle ilgili sorun, özellikle Java'nın bir konteynırda ikamet etmesi, entegrasyon testinin zor olması. Bu nedenle, büyük projelerde sistem entegrasyon testlerini kolaylaştırmak için, geliştiricinin kodlaması gereken proje için özel olarak yapılmış bir test çerçevesi gereklidir. Son zamanlarda bu alanda büyük gelişmeler kaydedilmiştir ve Arquillian gibi platformlar bir test çerçevesinin yazılmasını büyük ölçüde kolaylaştırmaktadır (hatta değiştirmektedir).

Gerçek dünyada, yalnızca ekibinizin / patronunuzun sizi sorumlu tuttuğu kadar sorumlu olursunuz. Her köşe başı ve huysuz kenar vakasını bulmak için hiç durmadan para harcamak veya ihbar etmek ve patronunuzun (veya daha kötü pazarlamanın) ticari mantık hatalarını yorumlamak için hevesine atlamak durumundaysanız, her şeyden öte, her şeyden siz sorumlusunuz.

Başka bir deyişle, size verilen kapsamın gerektirdiği şeyi yapın. Bazı genel anlamıyla atmak veya başkalarının oluşturduğunuz ürünü, kullanım durumları ve düzeltilmesi muhtemel sorunları anlamak için kullandıklarını görmek, ancak bunları "sabitlemeden" önce ekibinize veya patronunuza getirmek için kullanmak güzel bir ekstradır. Bu, seçtiğiniz araçları içerir. Tüm çabalarınız herkesin üzerinde olduğu bir şey olmalıdır.

Sorunuz yararlı hata takibi ise, iletişim sistemleri açısından bugzilla, google docs, zendesk veya basecamp'ı severim.

Bunun zaten kapsandığını sanmıyorum - kaçırdıysam özür dilerim.

Bir sorun, geliştiricilerin zamanının verimli kullanılmasıdır.

Geliştiriciler genellikle belirli test türlerinde iyi olma becerilerinden yoksundur. Kısmen, bu sadece doğal. Yazarların editörlere sahip olmalarının aynı nedeni. Eğer bir şeyde eksiklikleri görmek çok yakınsa çok zor. Ancak farklı yetenekler ve farklı özellikler ile de ilgilidir.

Durum böyle olunca, geliştiricinin zaman testi testinin maliyeti düşüktür: Fayda şartları. Bu geliştirici başka şeyler yaparken daha üretken olur ve uzman bir testçi testi yaparken daha üretken olur.

Tabii ki bu mutlaka geçerli olmayan çeşitli varsayımlarda bulunuyor. Örneğin, küçük bir şirkette test konusunda uzman kişilerin işe alınması mantıklı gelmeyebilir. Her ne kadar, fazladan destek personeli istihdam etmek ve bazı testler yaptırmalarını sağlamak veya en azından insanların kendilerinin yazmadığı kodları test etmek için daha anlamlı olabilir.

KG için yayınlanmadan önce olası tüm test senaryolarını kapsamamızın (aynı zamanda bir geliştirici) sorumluluğumuz olduğuna inanıyorum. KG'nin amacı yazılımı doğrulamaktır . Artı, hatalar için kendi kodunuzu kırmak her zaman QA zamanında iyi görünmenizi sağlar.

Bir geliştiriciden daha iyi kim, hangi test durumlarının en alakalı olduğunu bilir. Geliştirici, tüm birim testlerini yapmaktan sorumlu olmalı, mümkünse, geliştirici test komut dosyalarının yazılmasına ve yürütülmesine yardımcı olmalıdır. Bu nadiren büyük projelerde mümkün olduğundan, geliştiriciye tüm test durumlarını gözden geçirmesi için zaman verilmelidir. Ayrıca geliştirici bilgisine sahip olmalı ve mevcut çok çeşitli otomatik test araçlarını kullanmalıdır.

Geliştirme kariyerimde, projelerin daha iyi sonuçlarla sonuçlandığını ve geliştirme ekipleriyle test ekipleri arasında sıkı bir entegrasyon olduğunu buldum.

Her takımdan en az bir üye diğerlerinin de planlama ve uygulama toplantılarına katılmalıdır.