Nama baru untuk unit test [ditutup]


9

Saya tidak pernah suka pengujian unit. Saya selalu berpikir itu meningkatkan jumlah pekerjaan yang harus saya lakukan.
Ternyata, itu hanya berlaku dalam hal jumlah sebenarnya baris kode yang Anda tulis dan lebih jauh lagi, ini sepenuhnya diimbangi dengan peningkatan jumlah baris kode bermanfaat yang dapat Anda tulis dalam satu jam dengan pengujian dan pengembangan yang didorong oleh pengujian.

Sekarang saya suka tes unit karena memungkinkan saya untuk menulis kode yang berguna, yang cukup sering berfungsi pertama kali! (amit-amit)

Saya telah menemukan bahwa orang-orang enggan melakukan tes unit atau memulai proyek dengan pengembangan yang didorong oleh tes jika mereka berada di bawah garis waktu yang ketat atau dalam lingkungan di mana orang lain tidak melakukannya, jadi mereka tidak melakukannya. Agak suka, penolakan budaya bahkan untuk mencoba.

Saya pikir salah satu hal paling kuat tentang pengujian unit adalah keyakinan bahwa itu memberi Anda untuk melakukan refactoring. Ini juga memberikan harapan baru yang ditemukan, bahwa saya dapat memberikan kode saya kepada orang lain untuk memperbaiki / meningkatkan, dan jika unit test saya masih berfungsi, saya dapat menggunakan versi baru perpustakaan yang mereka modifikasi, cukup banyak, tanpa rasa takut.

Aspek terakhir dari unit testing ini yang saya pikir perlu nama baru. Tes unit lebih mirip kontrak apa yang harus dilakukan kode ini sekarang, dan di masa depan.
Ketika saya mendengar kata pengujian, saya memikirkan tikus dalam kandang, dengan beberapa percobaan dilakukan pada mereka untuk melihat efektivitas senyawa. Ini bukan pengujian unit, kami tidak mencoba kode yang berbeda untuk melihat apa pendekatan yang paling efektif, kami mendefinisikan output apa yang kami harapkan dengan input apa. Dalam contoh tikus, tes unit lebih seperti definisi tentang bagaimana alam semesta akan bekerja sebagai lawan dari percobaan yang dilakukan pada tikus.

Apakah saya bingung atau ada orang lain yang melihat penolakan ini untuk melakukan pengujian dan apakah mereka pikir itu alasan yang sama mengapa mereka tidak mau melakukannya?
Apa alasan Anda / orang lain untuk tidak menguji?
Menurut Anda, motivasi mereka bukan pada pengujian unit?

Dan sebagai nama baru untuk pengujian unit yang mungkin dapat mengatasi beberapa keberatan, bagaimana dengan jContract? (Sedikit Jawa sentris saya tahu :), atau Kontrak Unit?


14
Apa namanya? apa yang kita sebut mawar Dengan nama lain akan berbau manis; - Shakespeare, Romeo and Juliet, c.1600
Steven A. Lowe

8
Saya tidak tahu apakah Anda sedang retak. Saya belum pernah mencoba crack, atau menjadi Anda.
Tim Post

1
Saya berpikir bahwa ide-ide melekat pada kata-kata sebagian besar karena ide-ide dan sikap yang melekat padanya, bukan kata-kata. Saya ingat mengetahui bahwa Spastics Society telah mengubah namanya menjadi Scope, karena nama itu dikaitkan dengan prasangka. Saya ingat karena itu menjelaskan mengapa saya mendengar anak-anak memanggil satu sama lain "lingkup" sebelumnya hari itu. Jika Anda ingin mengubah sikap, fokuslah pada sikap, bukan nama - terobsesi pada nama itu hanya membuang waktu.
Steve314

2
Desain oleh Kontrak: en.wikipedia.org/wiki/Design_by_contract Memiliki konotasi tertentu, dan tes unit bukan. Jika saya melihat sesuatu dengan nama Kontrak, itu (dan antarmuka) adalah apa yang otak saya kaitkan dengannya.
Berin Loritsch

@ Steve314 Scopey. Suka itu. :) Saya pikir dalam hal ini, pengujian kata sudah didefinisikan, dan dengan demikian pengubahan nama pengujian unit menjadi istilah yang tidak ditentukan akan lebih baik. Kontrak tidak bisa karena 'antarmuka' yang disebutkan. Bagaimana dengan 'membuat program yang lebih baik lebih cepat' atau CBPF.
Will

Jawaban:


5

Apakah saya bingung atau ada orang lain yang melihat penolakan ini untuk melakukan pengujian dan apakah mereka pikir itu alasan yang sama mengapa mereka tidak mau melakukannya?

Pengujian kata dalam pengujian unit membuat orang berpikir ini adalah pengujian integrasi atau pengujian antarmuka pengguna karena hanya itulah jenis pengujian yang pernah mereka lakukan. Ini seperti menempatkan java ke javascript.

Ketika sesuatu memiliki nama yang buruk dan itu mempengaruhi pemikiran orang-orang tentang hal itu disebut kesalahan pembingkaian. Kesalahan pembingkaian cenderung dangkal - orang pintar dan dapat melihat semua jenis nama buruk, metafora buruk.

Apa alasan Anda / orang lain untuk tidak menguji?

Ketergantungan yang sulit untuk diejek / dipalsukan /

Menurut Anda, motivasi mereka bukan pada pengujian unit?

Pengujian unit memiliki jumlah konsep yang sederhana dan jumlah pekerjaan yang tidak sepele perlu dilakukan sebelum seseorang berhenti menulis tes unit yang buruk dan mulai menulis yang baik. Ketika orang menjadi lebih baik dalam menjelaskan apa itu unit testing, adopsi akan meningkat. Dalam pengalaman saya, pengujian unit memiliki efek magis dekat pada produktivitas dan kualitas kode. Tapi itu tidak dimulai seperti itu. Saya awalnya menggunakan kerangka pengujian unit sebagai cara yang nyaman untuk menulis tes integrasi.


Poin bagus. Mencoba menjelaskan mengapa Anda akan 'menguji' metode mendapatkan yang sederhana itu sulit, menjelaskan mengapa itu penting secara kontrak untuk stabilitas semua sisa kode Anda bahwa metode get selalu mengembalikan apa yang Anda harapkan adalah argumen yang lebih mudah untuk dibuat
Will

3

Konsep perubahan nama telah disahkan. Ini disebut Pengembangan Berbasis Perilaku . Orang-orang yang datang dengan itu memperhatikan banyak argumen yang sama ditambah kecocokan yang tidak wajar untuk menguji sesuatu yang belum dibuat. Alih-alih, konsep mereka adalah menulis spesifikasi yang dapat dieksekusi (yang sebenarnya adalah tentang TDD).

Saya perhatikan pushback yang sama. Saya juga memperhatikan bahwa sejumlah orang tidak tahu bagaimana menulis unit test. Mereka kurang dalam disiplin proses ilmiah, dan hanya menggunakan kerangka uji unit sebagai cara untuk menyatukan semuanya dan memulai debugger. Singkatnya, mereka tidak benar-benar meningkatkan penggunaan waktu mereka. Saya tidak bisa memberi tahu Anda berapa banyak unit test yang saya lihat yang panjangnya puluhan baris (lebih dari 30 baris) dan bukan satu pernyataan tegas. Ketika saya melihat itu, saya tahu sudah waktunya untuk bekerja dengan pengembang dan mengajari mereka apa itu penegasan, dan bagaimana menulis unit test yang benar-benar diuji.


2
Spesifikasi yang dapat dieksekusi mungkin ada sebelum TDD / BDD / Agile / XP. Mungkin setua CMMI. Dulu co-fad dengan UML ketika orang berpikir bahwa UML adalah bahasa untuk menulis ES.
rwong

BDD, seperti TDD, adalah pendekatan untuk pengujian, bukan semacam pengujian (fungsional v integrasi v penerimaan unit v). Penulis bertanya secara spesifik tentang nama "lebih baik" untuk pengujian unit.
ybakos

0

Kontrak disebut "antarmuka" dalam banyak kasus di sini. Memiliki unit test tidak menjamin kontrak sendiri, karena Anda dapat mengubah tes juga, jadi Anda tidak benar-benar tahu bahwa Anda dapat menggunakan versi baru perpustakaan hanya karena perpustakaan diuji. Anda perlu menguji kode yang menggunakan perpustakaan juga. Itu tidak berbeda dari pengujian unit lain, jadi saya tidak melihat mengapa itu perlu nama baru.

Saya pikir, seperti Anda, bahwa kebanyakan orang enggan melakukan tes karena mereka pikir itu lebih banyak pekerjaan dan tidak ada gunanya.


0

Saya akan memberi tahu Anda mengapa saya tidak suka TDD: ini bukan karena saya tidak bisa melihat nilainya di dalamnya, atau mengenali manfaat suite uji yang dapat saya jalankan untuk memverifikasi semua kode saya setelah setiap modifikasi.

Itu karena saya tidak membutuhkannya. Saya seorang siswa sekolah yang cukup tua, ketika saya masih kecil, kami tidak memiliki debugger terintegrasi yang mewah dengan edit-dan-terus menulis kode, dan kompilasi dapat memakan waktu yang cukup lama sehingga kami harus mendapatkan sesuatu benar, benar dari awal. Dengan pelatihan seperti itu, saya tidak benar-benar melihat bahwa menulis banyak unit test akan membuat saya lebih produktif atau kode saya lebih bebas bug.

Saya memang menguji kode saya, tetapi seperti yang selalu saya lakukan, ini lebih pada keseluruhan daripada pada masing-masing bagian. Jadi mungkin saya memang memiliki 'unit test', tetapi mereka agak berbutir kasar.

Jadi itulah alasan saya. Saya tidak dapat melihat perlunya bagi saya untuk melakukannya. Kode yang saya hasilkan cukup baik dan jika itu masalahnya, mengapa saya harus mengubah proses saya untuk memperbaiki sesuatu yang tidak rusak?


Anda harus menulis kode yang sangat sederhana. Jumlah negara yang dapat dijangkau dalam kebanyakan sistem modern berarti bahwa untuk melakukan pengujian ujung ke ujung akan memakan waktu seumur hidup alam semesta - pengujian dua potong masing-masing dengan 4bit negara membutuhkan 16 kasus untuk menguji masing-masing, atau total 32 kasus uji; dibuat menjadi sistem end-to-end memberikan 8bit negara atau 256 kasus uji untuk mencakup semua negara. Secara pribadi, saya lebih suka melakukan 1/8 pekerjaan.
Pete Kirkham

1
@PeteKirkham akibat wajarnya adalah bahwa Anda perlu menulis sejumlah besar tes unit dan kemudian juga menulis tes integrasi untuk memastikan unit tersebut masih saling bekerja. Tempat saya bekerja yang sangat menyukai tes unit menghabiskan begitu banyak waktu menulis (dan memelihara) mereka sehingga mereka mengerdilkan basis kode, dan jumlah pekerjaan yang mereka lakukan sangat kecil dibandingkan dengan apa yang saya capai di luar lingkungan itu. Tidak ada yang merupakan peluru ajaib, saya sarankan mencoba untuk menemukan pendekatan yang lebih pragmatis yang memberi Anda berdua cakupan tes dari bit-bit penting sambil juga menghasilkan sesuatu.
gbjbaanb
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.