Tes unit refactor?
Saat kami bekerja dengan kode lama dan perlu melakukan perubahan, pertama-tama kami menulis pengujian pada perilaku saat ini. Dengan begitu kami dapat menerapkan perubahan baru dengan percaya diri. Kami bahkan dapat memfaktor ulang kode.
Kode lama sering kali merupakan kode yang buruk, dan setelah beberapa pemfaktoran ulang, kode tersebut mungkin lebih sederhana, lebih mudah untuk diuji. Karena refactor telah divalidasi oleh pengujian, haruskah kita juga melakukan refaktorisasi pengujian jika kita dapat membuatnya lebih sederhana / jelas atau menyimpannya seperti yang tertulis?
Jawaban
Pengujian otomatis adalah kode, jadi mempertahankan kode ini masuk akal, termasuk pengujian pemfaktoran ulang jika sesuai. Namun:
kode dan pengujian produktif memiliki persyaratan kualitas yang berbeda
- jangan menginvestasikan waktu untuk hal-hal yang tidak penting
kode produktif harus memiliki satu sumber kebenaran, sedangkan tes sebagian besar harus berdiri sendiri
- duplikasi tidak selalu buruk
Dan seperti yang ditunjukkan Ewan, Anda tidak boleh mengubah kode dan tes pada saat yang bersamaan. Bersama-sama, pengujian kode + adalah sistem pengujian mandiri. Perubahan di satu bagian diverifikasi dengan menjalankannya bersama-sama dengan bagian lainnya. Mengubah keduanya pada saat yang sama melepaskan keamanan ini. Hal ini tidak selalu mungkin dalam praktiknya (misalnya saat mengubah masalah lintas sektor seperti pustaka standar yang mendasarinya), tetapi akan bodoh untuk melepaskan keselamatan ini tanpa kebutuhan yang sangat kuat.
Alasan umum saya memfaktorkan ulang pengujian, tanpa urutan tertentu: API yang sedang diuji telah berubah, beralih ke pendekatan pengujian yang berbeda (mis. Pengujian berbasis skenario vs pengujian berbasis properti, pengujian tingkat API vs pengujian tingkat perilaku), mengubah kerangka kerja pengujian (misalnya untuk mendapatkan laporan kegagalan yang lebih baik atau menggunakan pengujian parametrized), mengubah organisasi pengujian (misalnya suite dan kasus gaya xUnit vs mendeskripsikan gaya RSpec-it), menyingkirkan akumulasi duplikasi (misalnya mengekstrak kode umum untuk membuat perlengkapan) ,…
Saat kami bekerja dengan kode lama dan perlu melakukan perubahan, pertama-tama kami menulis pengujian pada perilaku saat ini. Dengan begitu kami dapat menerapkan perubahan baru dengan percaya diri. Kami bahkan dapat memfaktor ulang kode.
Itu terkadang mencerminkan proses kerja Anda, tetapi menurut pengalaman saya, cara yang lebih efisien adalah:
Anda menulis tes
Anda refactor untuk membuat perubahan lebih mudah
Anda menerapkan perubahan tersebut
Dengan cara ini, menjadi lebih jelas bahwa Anda melakukan refactor ketika ada alasan nyata untuk perubahan , bukan hanya karena kode "tidak bersih lagi".
Sekarang coba terapkan ukuran yang sama untuk pengujian Anda: Anda tidak melakukan refactor pengujian Anda karena "mereka tidak bersih lagi" . Anda memfaktorkan ulang mereka ketika mereka mulai menghalangi Anda untuk membuat perubahan mudah pada kode yang ada.
Misalnya, jika Anda memiliki sepuluh pengujian yang semuanya memanggil metode publik yang sama dari kelas yang sedang diuji, sementara dalam kode produksi Anda metode publik itu hanya dipanggil di satu tempat, maka ini adalah bentuk duplikasi kode oleh pengujian yang dapat menghalangi Anda untuk melakukannya. mengubah tanda tangan metode publik itu.
Saya biasanya membiarkannya seperti itu kecuali Anda benar-benar mendapatkan persyaratan untuk yang terakhir, atau yang lebih umum: ketika Anda melihat duplikasi kode ini mengharuskan Anda untuk membuat perubahan yang sama pada pengujian Anda di beberapa tempat.
Anda mungkin ingin memulai dengan memfaktorkan ulang pengujian.
Tes menangkap apa yang dilakukan aplikasi lama; semacam dokumentasi. Pengujian memberi tahu Anda masukan dan keluaran, kode memberi tahu Anda proses. Jika tesnya buruk maka merapikannya (tergantung seberapa buruknya) akan membantu Anda memahami kodenya.
Ini juga cara yang bagus untuk menilai apakah tes menambah nilai; sistem warisan yang saya kerjakan memiliki cakupan kode yang bagus tetapi pada pemeriksaan pengujian menegaskan hal-hal yang tidak berguna ... seperti memastikan Getters dan Setter bekerja (menguji kerangka .NET bukan aplikasi).
Setelah Anda mendapatkan tes bersih, Anda akan memiliki pemahaman yang lebih baik tentang kode, dan kemudian Anda dapat membuat keputusan yang lebih baik tentang cara memfaktorkan ulang kode.