Perbedaan Antara Unit Pengujian dan Pengembangan Didorong Uji

64

Dari membaca deskripsi, saya mengerti bahwa dalam tes TDD dilakukan sebelum menulis fungsi dan di Unit Testing, setelah itu dilakukan.

Apakah ini perbedaan utama, atau kedua istilah itu bahkan tidak dapat dibandingkan. Mungkin, Unit Testing adalah bagian terintegrasi dari TDD.

unit-testing tdd difference

— Shamim Hafiz
sumber

104

Unit Pengujian mengacu pada apa yang Anda menguji, TDD untuk saat Anda menguji.

Keduanya orthogonal.

Unit Testing berarti, baik, menguji unit perilaku individu. Unit perilaku individu adalah unit perilaku terkecil yang dapat diuji secara terpisah. (Saya tahu bahwa kedua definisi itu melingkar, tetapi dalam praktiknya tampaknya cukup berhasil.)

Anda dapat menulis unit test sebelum Anda menulis kode Anda, setelah Anda menulis kode Anda atau saat Anda menulis kode Anda.

TDD berarti (sekali lagi, agak jelas) membiarkan tes Anda mendorong pengembangan Anda (dan desain Anda). Anda dapat melakukannya dengan tes unit, tes fungsional, dan tes penerimaan. Biasanya, Anda menggunakan ketiganya.

Bagian terpenting dari TDD adalah D tengah . Anda membiarkan tes mendorong Anda. Tes memberi tahu Anda apa yang harus dilakukan, apa yang harus dilakukan selanjutnya, ketika Anda selesai. Mereka memberi tahu Anda apa yang akan menjadi API, apa desainnya. (Ini penting: TDD bukan tentang menulis tes terlebih dahulu. Ada banyak proyek yang menulis tes terlebih dahulu tetapi jangan berlatih TDD. Tes menulis terlebih dahulu hanyalah prasyarat untuk dapat membiarkan tes mendorong pengembangan.)

— Jörg W Mittag
sumber

1

Jawaban yang bagus akan menambahkan ... TDD adalah ketika Anda membiarkan tes untuk mendorong Anda dan fitur untuk menarik upaya pengembangan Anda ...

— Martin

Mereka tidak ortogonal. Anda tidak dapat memiliki TDD tanpa tes unit.

— JacquesB

1

@ JacquesB, mengapa? Pengujian kami bukanlah apa yang Anda sebut pengujian unit dengan definisi apa pun, mereka terlalu bergantung pada infrastruktur dan komponen lainnya, tetapi kami masih memiliki cukup kemampuan pengamatan sehingga kami - setidaknya sebagian dari kita - melakukan TDD.

— Pemrogram

3

@AndrewWillems: TDD berarti bahwa tes mendorong pengembangan . Anda tidak memutuskan seperti apa desainnya, tes memberi tahu Anda. Anda tidak memutuskan apa yang harus dilakukan selanjutnya, tes memberitahu Anda. Anda tidak memutuskan kapan Anda selesai, tes memberitahu Anda. Sangat mungkin untuk menulis tes terlebih dahulu, dan kemudian mengabaikan semua yang mereka katakan kepada Anda. Misalnya, Anda dapat menulis tes terlebih dahulu, tetapi kemudian tetap menulis kode bahkan setelah semua tes berwarna hijau. Jadi, dengan kata lain: Anda menulis tes terlebih dahulu, tetapi Anda memperlakukannya hanya sebagai tes, dan jangan biarkan mereka mendorong perkembangan.

— Jörg W Mittag

1

@ JörgWMittag Anda mungkin benar dalam cara yang murni dalam memandangnya, tetapi Anda juga tahu bahwa TDD tidak hitam dan putih. Setiap penggunaan TDD yang waras tidak akan membiarkan tes mendorong pengembangan sepenuhnya, dan tes pasti tidak selalu memutuskan seperti apa desainnya (mungkin unit test sebagian dapat melakukan ini, tetapi tidak tes pada tingkat abstraksi yang lebih tinggi). Bagaimana dengan refactoring? Yang merupakan aspek yang sangat penting dari TDD. Juga di dunia nyata tidak ada yang namanya 'abaikan semua yang diceritakan tes Anda'. Menurut definisi, jika Anda menulis tes terlebih dahulu, Anda menggunakan 'beberapa bentuk TDD'.

— NickL

21

Unit Testing adalah komponen dari Test Driven Development

Anda dapat melakukan pengujian unit tanpa melakukan pengembangan berbasis pengujian. Namun Anda tidak dapat melakukan pengembangan yang didorong oleh tes tanpa menggunakan unit test.

Ketika Anda melakukan pengujian unit tradisional , Anda menulis tes setelah Anda menulis kode Anda.

Pendekatan pengembangan yang digerakkan oleh tes adalah menulis unit test sebelum menulis kode.

Keuntungan paling menarik dari TDD (IMHO) dibandingkan dengan Unit Testing sederhana:

Kode sepenuhnya diuji di muka kode. Ini pengujian tanpa rasa sakit.
Ini memaksa Anda untuk merancang kelas Anda dengan benar.
Ini juga memaksa Anda untuk tetap bodoh .
Siklus Red-Green-Refactor adalah pembunuh prokrastinasi absolut!

Apakah Anda melewatkan "unit" dengan sengaja di statment: "Namun Anda tidak dapat melakukan pengembangan yang digerakkan oleh pengujian tanpa menggunakan pengujian." ?

— ratkok

@ratkok: tidak, itu tidak sengaja. Biarkan saya memperbaikinya.

Saya suka definisi ini yang terbaik. Lebih baik disatukan dalam kata-kata daripada jawaban lainnya.

— Tek

2

Dapat diperdebatkan, Anda dapat melakukan TDD menggunakan tes modul atau tes sistem daripada tes unit sejati. Saya tidak akan menyarankan itu, karena Anda kehilangan banyak manfaat jika tes terlalu lama untuk dijalankan, tetapi itu bukan tidak mungkin.

— Toby Speight

13

TDD dan Unit Testing adalah dua istilah yang sangat spesifik yang sering disalahgunakan.

TDD sedang menulis tes yang akan gagal, kemudian menulis jumlah minimum kode yang diperlukan untuk membuatnya berjalan, kemudian refactoring kode untuk membuatnya bersih. Ini dilakukan dalam siklus, gagal -> lulus -> refactor, menambahkan tes baru untuk setiap persyaratan yang diketahui untuk kode. Baru-baru ini, TDD telah menjadi lebih khusus lagi tentang penulisan unit test dalam siklus itu, untuk membedakannya dari ATDD (subset dari BDD) yang menulis tes penerimaan dalam siklus yang sama.

Unit Testing adalah tentang menguji kode dalam unit kecil yang terisolasi. Kebingungan umum di sini adalah berpikir bahwa jika Anda menggunakan alat pengujian unit, seperti xUnit atau Rspec, untuk menjalankan tes yang Anda tulis adalah tes unit. Ini belum tentu benar. Alat-alat itu dapat digunakan untuk menjalankan tes katakan menggunakan kerangka Selenium - dalam hal ini Anda menulis tes penerimaan menggunakan unit test runner. Tes unit adalah tes yang sangat khusus yang berfokus pada sepotong kecil logika, terisolasi dari segala hal lain demi kecepatan (sehingga Anda dapat menjalankannya sering dan mendapatkan umpan balik cepat tentang bug baru).

— pdr
sumber

1

Tes JUnit untuk JUnit itu sendiri adalah contoh yang baik: sebagian besar dari mereka adalah tes fungsional dan tes penerimaan, bukan tes unit, meskipun ditulis dalam JUnit. Juga, pencipta JUnit juga merupakan pencipta TDD, dan JUnit dikembangkan menggunakan TDD menggunakan sejumlah besar tes fungsional dan tes penerimaan. Pengujian penerimaan merupakan bagian integral dari TDD.

— Jörg W Mittag

6

TDD adalah pendekatan penulisan kasus uji sebelum pengembangan seperti yang Anda katakan dan kemudian pengembang menulis kode untuk lulus kasus uji. Unit Testing adalah istilah yang digunakan untuk menggambarkan jenis pengujian lingkup sempit selain pengujian sistem, pengujian integrasi dan pengujian penerimaan.

— M.Sameer
sumber

3

TDD adalah pendekatan filosofis untuk menulis kode: tulis tes terlebih dahulu. Tes yang Anda tulis adalah tes unit.

— Tangurena
sumber

1

Cara saya memisahkan keduanya adalah dengan mempertimbangkan bahwa TDD lebih sedikit tentang pengujian, dan lebih banyak tentang merancang kode. Tes unit kemudian digunakan untuk menetapkan harapan untuk kode akhir. Ketika kode akhir ditulis, dan lulus tes (spesifikasi), Anda memiliki kode yang dirancang menggunakan tes.

— Grant Palin
sumber

1

Semua jawaban bagus. Saya hanya akan menambahkan bahwa pengujian unit cenderung menganggap 'unit' sebagai komponen kecil, sementara TDD meningkatkan untuk memasukkan tes integrasi dan penerimaan.

(Beberapa varian TDD menganggap 'unit' sebagai langkah inkremental terkecil menuju fungsionalitas yang diinginkan ...)

— Steven A. Lowe
sumber

mereka seharusnya, tetapi dalam pengalaman saya dalam kenyataan mereka tidak. Perusahaan / kelompok mengatakan mereka melakukan TDD, ketika semua yang mereka lakukan adalah memaksa programmer untuk melakukan tes pertama dengan tes jUnit, kemudian gunakan fakta bahwa semuanya sudah diuji selama pengembangan untuk menghilangkan (atau sangat mengurangi) QA dan pengujian integrasi.

— jwenting

1

@ jwenting jangan salahkan metodologi atas kekurangan mereka yang mengaku mempraktikkannya. alat apa pun dapat disalahgunakan

— Steven A. Lowe

1

Saya tidak, tetapi Anda harus menyadari bahwa ada perbedaan besar antara apa itu TDD dalam teori dan apa itu dalam kenyataan. Dan karena kebanyakan orang (termasuk OP) mungkin hanya pernah melihat kenyataan, perbedaannya harus ditunjukkan kepada mereka.

— jwenting

Menimbang bahwa TDD adalah tentang desain - mengapa itu termasuk pengujian penerimaan? bagaimana itu "mendorong" desain?

— Vitalii Isaenko

Tes penerimaan @VitaliiIsaenko memberikan pelingkupan tingkat tertinggi untuk desain

— Steven A. Lowe