Apa yang Anda sebut pengembang test suite berjalan sebelum checkin? [Tutup]

Saya sedang mengerjakan proyek tempat kami menambahkan pengujian otomatis ke proyek yang ada. Kami mulai dengan komponen pusat, dan menyiapkan kedua tes unit di tingkat modul kode, dan tes yang berjalan di seluruh komponen, meskipun di lingkungan pengembang. Maksudnya adalah bahwa rangkaian tes ini harus lulus sebelum kode masuk, dan akan dijalankan oleh sistem integrasi berkelanjutan pada setiap cabang pengembangan.

Apa yang harus kita sebut ini? Saat ini kami menyebutnya "unit dev tes", tetapi sisi pedantic dari saya mengatakan itu tidak benar, karena berisi lebih dari unit test. Dan visi kami adalah bahwa rangkaian ini akan tumbuh seiring waktu untuk memasukkan tes penerimaan produk lengkap.

Ada masukan di sini? Atau haruskah kita berhenti berdebat tentang nama dan menulis tes?

Memperbarui

Semuanya, terima kasih atas diskusi yang baik! Saya pikir kesimpulan yang saya sampaikan adalah bahwa tidak ada definisi "umum" - setiap proyek / tim menghasilkan nama yang paling masuk akal untuk proyek itu, tergantung pada teknologinya (Java, C #, ruby, dll) dan metodologi (air terjun old-skool, Scrum, XP, dll) digunakan.

Mereka dikenal sebagai "Gated check-in" di MSFT TFS. http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx

Panggil mereka apa pun yang Anda inginkan, tidak masalah. Yang penting adalah kualitas tes dan dijalankan.

Tes kami adalah Tes Penerimaan Otomatis, tetapi kami menyebutnya "tes" di sini di tempat kerja saya. Seperti dalam:

• perbaiki "tes" Anda
• Anda memecahkan "tes"
• apakah Anda menulis "ujian"
• "tes" ini payah, jadi saya menulis ulang

Saya menyebutnya "tes" dengan implikasi bahwa saya berbicara tentang "tes unit otomatis" dan dengan implikasi wajar bahwa ini cepat (beberapa detik hingga beberapa menit adalah apa yang saya alami lebih sering.

Terkadang akan ada tes lain yang berjalan secara otomatis pada saat check-in, atau sekali pada malam hari misalnya. Ini cenderung memakan waktu lebih lama. Sesuatu antara 30 menit dan beberapa jam. Biasanya kita menyebutnya "tes fungsional", atau "tes regresi" atau bahkan "tes lambat".

Dari pengalaman saya:

Tes unit adalah tes atau serangkaian tes yang mencakup modul tertentu. Dalam pemrograman OO, modul biasanya fungsi atau kelas. Tes unit dikelompokkan ke dalam suite tes. Tes unit adalah blok pembangun uji regresi dan asap, dan dalam beberapa kasus dapat berfungsi sebagai dokumentasi untuk perilaku yang diinginkan dari suatu sistem atau bagian-bagian dari suatu sistem.

Pengujian regresi adalah tindakan menjalankan sebagian besar atau semua tes unit pada modul yang diubah. Ini memastikan bahwa modul yang diubah terus bekerja seperti yang diharapkan mengikuti perubahan.

Pengujian asap adalah tindakan menjalankan (kecil - Anda ingin pengujian asap menjadi cukup cepat) sejumlah unit tes pada modul yang tidak berubah untuk memastikan bahwa perubahan pada modul tidak memiliki efek samping yang tidak diinginkan pada modul lain. Fokusnya biasanya pada kelas yang memiliki asosiasi dengan kelas yang diubah serta modul yang menyediakan fungsionalitas utama untuk aplikasi.

Bergantung pada lingkungan build Anda, semua ini mungkin otomatis atau dieksekusi oleh pengembang. Perangkat perubahan yang berkomitmen harus cukup kecil sehingga tes regresi tidak memakan waktu terlalu lama, dan pengujian asap dirancang agar cukup cepat. Biasanya, saya menjalankan setidaknya regresi dan tes merokok pada kode sebelum bahkan diperiksa jadi saya tidak merusak build. Saya biasanya melihat sistem build dirancang untuk mengeksekusi dan melaporkan status semua kasus uji secara teratur, mulai dari harian hingga mingguan tergantung pada tingkat pengembangan dan waktu untuk membangun dan menjalankan tes.

Jika Anda menjalankannya di basis kode sebelum check in, itu adalah tes regresi.

jika Anda hanya menguji bit yang Anda ubah itu adalah unit test.

Saat Anda menambahkan tes untuk bug tingkat sistem, lalu memperbaikinya, itu adalah uji regresi.

Tesnya jika Anda mundur: mundur.

Layak untuk melakukan tes regresi karena bug cenderung mengelompok di tempat-tempat tertentu, dan beberapa bug berulang.

Jika Anda dapat bertahan dengan disiplin memiliki tes tingkat sistem, menambahkan tes regresi ada hasilnya. Setiap sub-sistem yang rapuh berakhir dengan uji regresi.

Kisah nyata.

Tes Unit Otomatis adalah apa yang saya selalu menyebutnya.

Saya tidak yakin apakah ada istilah resmi atau tidak, tetapi saya akan menyebutnya Tes Otomatis. Saya setuju dengan Anda unit kata yang ada di sana tidak akurat.

Istilah "Tes Otomatis" mencakup spektrum dari Tes Unit, Tes Regresi, Tes Integrasi, Tes Penerimaan, dll.

Kami biasanya menyebutnya tes asap, tes kewarasan atau tes prioritas 1. Tes prioritas 2 terjadi setelah checkin dan kemudian tes prioritas 3 dijalankan pada build terjadwal. Serangkaian tes terakhir kami, tes prioritas 4, terjadi ketika kami memiliki bangunan khusus yang terjadi selama akhir pekan - karena membutuhkan waktu yang lama untuk dijalankan.