Haruskah peninjauan kode dilakukan sebelum atau setelah pengujian unit

10

Saya berdebat dengan kolega saya tentang kapan harus melakukan tinjauan kode - sebelum atau setelah pengujian unit. Apa praktik terbaik?

Beberapa faktor yang perlu kita perhitungkan (mungkin ada lebih banyak):

Ukuran perubahan kode - perubahan besar berarti lebih banyak perubahan akan dihasilkan dari tinjauan kode. Jika perubahan ini lebih besar dari, jika UT sebelum ulasan kode, Anda harus mengulang sebagian besar UT Anda lagi.
Waktu yang dibutuhkan untuk melakukan tes unit
Apakah ini fungsionalitas baru atau perbaikan bug

language-agnostic code-reviews

— dimba
sumber

Saya pribadi tidak berpikir keduanya begitu tergantung satu sama lain. Pengembang hanya boleh meninjau kode lengkap, karena mungkin tidak lengkap atau tidak berfungsi seperti yang diharapkan.

— Lloyd Powell

20

Anda harus selalu menguji unit sebelum melakukan peninjauan kode dan inilah alasannya

Jika kode Anda rusak dengan cara yang akan tertangkap oleh unit test Anda akan membuang-buang waktu pengembang lain dengan melibatkan mereka dalam siklus merah / hijau / refactor.
Pengujian menunjukkan pengembang lain tentang tujuan penggunaan kode yang membuatnya lebih mudah untuk ditinjau.
Tes harus ditinjau bersama dengan kode yang diuji jika Anda kehilangan kasus uji atau tes Anda tidak berfungsi dengan baik.
Tes dan tinjauan kode cenderung menangkap masalah yang berbeda dengan hanya sedikit tumpang tindih dalam masalah yang ditemukan. Tes unit tidak merasa terganggu karena harus menguji ulang kode ketika pengulas menemukan masalah, pengembang memang merasa terganggu dan mungkin tidak akan melakukannya dengan baik untuk kedua kalinya.

Mungkin ada alasan lain, tetapi itulah yang saya lihat dan alami sendiri setelah menerapkan praktik tinjauan kode dalam 3 tim / perusahaan yang berbeda.

Sunting Tentu saja hal di atas adalah saat-saat ketika peninjauan kode merupakan langkah dalam proses pengembangan perangkat lunak Anda (baik air terjun atau gesit). Jika Anda sedang mengerjakan bagian kode yang sangat besar atau sulit, jangan ragu untuk melihatnya lagi kapan saja.

— Bryan Anderson
sumber

11

Ulasan Kode adalah untuk saat kode "selesai".

Di organisasi saya, definisi "selesai" kami meliputi pengujian unit (karena kami bertujuan untuk TDD) sehingga ulasan kode adalah kode lengkap - dan kode lengkap termasuk tes.

Selain itu, pengujian perlu ditinjau dan direfraktasi sehingga masuk akal bahwa itu adalah bagian dari tinjauan kode.

— Neil Thompson
sumber

Bukankah masuk akal untuk membuat review kode ke kode sebelum Anda menulis tes unit untuk itu?

— dimba

jika Anda memiliki tes dan tinjauan kode menyarankan perubahan pada kode, Anda dapat membuat perubahan pada kode dengan percaya diri karena didukung oleh tes. Tanpa tes, perubahan yang dihasilkan dari tinjauan kode dapat menyebabkan bug.

Ok, mungkin saya tidak menjelaskan diri saya baik. Yang saya maksudkan adalah kasus ketika kode Anda untuk fungsionalitas yang sama sekali baru namun belum dicakup oleh unit test. Apakah akan baik untuk melakukan tinjauan kode ke kode, sebelum Anda menulis tes unit untuk yang baru ini secara fungsional?

— dimba

Hai Dimba. Saya tidak yakin ada cara terbaik mutlak untuk jujur. Secara pribadi saya akan memiliki ulasan kode setelah tes ditulis, tetapi itu karena saya tahu diri saya dan preferensi orang yang bekerja dengan saya. Mungkin coba setiap teknik dan lihat mana yang Anda / tim Anda sukai? Yang utama adalah Anda memiliki tes - dilakukan dengan sangat baik di sana.

4

Tes harus dianggap sebagai bagian dari kode yang akan ditinjau. Karena itu masuk akal untuk meninjau kembali setelah tes dilakukan.

Pastikan tes ditinjau juga. Ini sangat penting bagi mereka yang baru dalam unit test.

Pastikan tim Anda mendapat injeksi ketergantungan, kerangka isolasi, ejekan vs bertopik, jahitan, tes berbasis interaksi vs kondisi, dan tes integrasi vs unit.

Anda tidak perlu menerapkan topik yang disebutkan di atas, tetapi Anda harus memahaminya.

— Scott Coates
sumber

2

Baik,

Ini tergantung pada apa yang Anda maksud dengan "Unit Test" ...

Jika itu adalah Tes Unit gaya TDD itu tidak ada artinya karena Anda menulis tes saat Anda menulis kode Anda. Tidak ada kasus after-later. Dalam hal ini Anda terus meningkatkan kualitas kode: Refactoring ...

DAN

Jika itu adalah klasik "unit test" [apa pun artinya saya tidak tahu, tetapi maksud saya tes setelah Anda menulis kode dan biasanya dilakukan oleh orang lain] maka kriteria utama adalah apa yang Anda harapkan dari codereview dan sifat unit test: jika Anda ingin umpan balik yang cepat - buat tinjauan dan lakukan tindakan dan tidak memiliki unit test otomatis, Anda harus menunggu unit test. Jika Anda ingin mengidentifikasi masalah matang dengan ulasan kode, dan secara bertahap menerapkan solusi untuk iterasi berikutnya, Anda dapat melakukannya sebelum unit test ...

Tapi bagaimanapun juga, untuk codereview, setelah atau nanti unit test bukanlah kriteria nyata bagi saya ...

Mengapa kami melakukan codereview? Untuk kualitas kode ... Alih-alih gerbang "kontrol kualitas", masukkan kualitas ke dalam proses pengembangan perangkat lunak Anda ...

@Terima kasih atas jawabannya. Mungkin saya tidak jelas, tetapi saya tidak merujuk ulasan kode sebagai semacam gerbang "kontrol kualitas" formal. Saya mencoba melihat apa yang "benar" cara dalam hal kecepatan / kualitas pengembangan

— dimba

2

Saya cenderung mengatakan, mari kita menjadi "gesit" ... jangan menunggu kode selesai untuk melakukan tinjauan kode yang cepat dan tidak resmi: ada pengembang dengan siapa dan subjek yang dapat Anda tunggu untuk keseluruhannya kode + fase uji yang harus diselesaikan ... tetapi

ketika datang ke subjek yang benar-benar baru (seluruh fitur baru, penelitian dekat, sesuatu yang sama sekali baru bagi tim), pengkodean kode awal, jangan kehilangan waktu: minta rekan kerja melihat dari waktu ke waktu: isolasi adalah faktor penting kegagalan dalam kasus ini.

jika pengembang baru dalam tim, tinjau kode awal dan mungkin sering .

dan omong-omong, unit test juga perlu ditinjau kode.

— lengan
sumber