Apa yang dimaksud dengan rasio “garis fungsional kode” normal dengan “jalur tes kode”?

27

Saya cukup baru dalam pendekatan TDD dan percobaan pertama saya mengatakan bahwa menulis 1 baris kode fungsional berarti menulis sekitar 2-3 baris kode pengujian. Jadi, jika saya akan menulis 1000 LOC, seluruh basis kode termasuk tes akan menjadi sekitar ~ 3500 LOC.

Apakah ini dianggap normal? Berapa rasio dalam kode yang Anda tulis?

— Andrey Agibalov
sumber

8

Ya, TDD hadir dengan label mahal!

— EL Yusubov

6

nomor 2-3X Anda paling konservatif , itu sebenarnya lebih dekat ke 4-5X untuk hal-hal seperti C # / Java, Python / Ruby mungkin lebih dekat dengan 2-3X, dengan sesuatu yang singkat seperti Erlang mendekati 1: 1. Bergantung pada seberapa dogmatis Anda tentang TDD, semakin dogmatis, semakin besar rasio yang didapat!

6

@tomwrong: Dalam buku Kent dia mengutip Ward bahwa Anda harus menulis tes sampai rasa takut Anda berubah menjadi kebosanan.

— herby

4

@ ElYusubov: Saya tidak setuju bahwa itu "mahal" sama sekali. Tampaknya begitu bagi mereka yang masih menghitung jumlah pekerjaan di LOC. Tetapi harga tidak di LOC, itu dalam uang dan waktu ke pasar. Dan di sana, TDD tidak lebih mahal daripada proses pengembangan wajar lainnya.

— herby

5

Kawan, mengapa Anda berkomentar alih-alih memposting jawaban? Apa yang Anda tulis masuk akal.

— Andrey Agibalov

18

1: 3 normal dengan TDD.

Dari pengalaman saya, dan juga dari kutipan lain yang saya ingat.

— herba
sumber

12

... kutipan apa?

— TehShrike

... samar-samar ingat ... Saya sudah tidak ingat di mana itu (mungkin di TDD Kent Beck Dengan Contoh, mungkin di suatu tempat di c2.com). Saya ingat artinya, bahwa kode pengujian tiga kali lebih banyak daripada kode produksi tidak apa-apa.

— herby

Wow, persis sama dalam pengalaman saya juga. (Saya menatap hasil dari cloc sekarang dan saya mencari google untuk menemukan posting pada rasio ini)

— Nikolay Tsenkov

9

Ada variasi berdasarkan gaya pengkodean dan bahasa yang berbeda. Namun, terlepas dari bahasa yang Anda gunakan, variasi terbesar adalah Anda.

Robert Martin pernah berkata:

"Ketika tes menjadi lebih spesifik, kode menjadi lebih umum."

Itu membuat saya berpikir. Tes yang lebih spesifik berarti lebih banyak kode tes. Kode produksi yang lebih umum berarti lebih sedikit kode, sehingga rasio uji / kode akan naik ketika kode berevolusi.

Tapi tunggu, itu juga tidak baik. Dalam beberapa kasus tertentu, misalnya ketika Anda mendefinisikan algoritma tertentu, Anda mungkin hanya memiliki 6-10 baris kode yang berisi beberapa "jika", beberapa saat dan mungkin 2-3 rekursi. Saya dapat memberitahu Anda, kode itu mungkin memiliki lebih dari 100 baris kode uji.

Dalam proyek nyata, sesuatu yang lebih besar dari hanya beberapa algoritma, rasio tes / kode harus berada di antara 1: 1 dan 2: 1. Jika mendapat di atas 2: 1, itu bau bahwa Anda memiliki tes yang harus di refactored atau dihapus (atau mungkin kode yang sulit untuk diuji). Anda harus selalu menginvestasikan jumlah perawatan dan refactoring yang sama dalam tes Anda seperti dalam kode produksi Anda.

Bagaimanapun, jawaban terbaik untuk pertanyaan Anda mungkin adalah "Kompleksitas Siklomatik" . Semakin tinggi kompleksitas siklomatik metode Anda, semakin banyak tes yang harus Anda tulis untuk mencakup semua kasus.

— Patkos Csaba
sumber

3

Rasio akan bervariasi tergantung pada ukuran metode Anda. Ukuran metode Anda akan bervariasi berdasarkan gaya pemrograman, bahasa, dan domain masalah.

Jika metode Anda pendek maka 3: 1 masuk akal. Jika metode Anda panjang, maka 3: 1 ada di sisi atas.

Jadi, untuk menjawab pertanyaan Anda, itu tergantung. :-)

— Jon Strayer
sumber

Itu tergantung pada apa yang Anda maksud dengan "metode yang panjang". Apa gambar yang dibuatnya di kepala saya, adalah bahwa metode tidak perlu lama, melakukan terlalu banyak pekerjaan dan memiliki terlalu banyak tanggung jawab (seringkali memiliki terlalu banyak parameter). Dalam hal ini, metode seperti itu membutuhkan kombinasi yang lebih proporsional untuk dicakup oleh tes, jadi saya tidak berpikir rasio akan banyak berubah ...

— herby

Asumsikan sesaat Anda dapat mengatur tes, panggil metode yang akan diuji dan periksa hasilnya dalam tiga baris kode. Jika metode yang Anda uji panjangnya satu baris (seperti yang terjadi dalam Scala) maka ransum pengujian untuk kode produksi Anda adalah 3: 1. Jika metodenya panjang enam baris maka itu 1: 2. Enam baris tidak terlalu panjang.

— Jon Strayer

2

Untuk aplikasi kritis perangkat lunak, rasio yang biasa dilakukan adalah satu hari pengujian untuk setiap 10 fungsional LoC.

Dan ini tidak termasuk TDD yang bukan tentang tes tetapi tentang spesifikasi.

— mouviciel
sumber

1

Ukuran kode pengujian saya sekitar setengah dari kode 'aktual' secara keseluruhan. Melakukan sebaliknya menunjukkan bahwa pengujian Anda terlalu kompleks dan / atau kode Anda terlalu sulit untuk diuji dan / atau kode Anda terlalu padat / kompleks.

Atau Anda hanya menguji terlalu banyak, dan membuang-buang waktu untuk pengembalian yang berkurang.

Lihat juga "kapan pengujian unit tidak tepat atau tidak perlu?"

— Telastyn
sumber

-1

Rasio saya sekitar 2-1 hingga 10-1 (kode untuk diuji). Pastikan Anda menguji tentang nilai / perilaku dan bukan implementasi.

— Erez A. Korn
sumber