Apakah ide yang baik untuk menulis semua kasus uji yang mungkin setelah mengubah tim menjadi TDD untuk mencapai cakupan penuh?


17

Asumsikan kita memiliki aplikasi tingkat perusahaan besar tanpa tes unit / fungsional. Tidak ada proses pengembangan yang digerakkan oleh tes selama pengembangan karena tenggat waktu yang sangat ketat (saya tahu kita seharusnya tidak pernah menjanjikan tenggat waktu yang ketat ketika kita tidak yakin, tetapi apa yang dilakukan sudah dilakukan!)

Sekarang setelah semua tenggat waktu berlalu dan semuanya tenang, semua orang sepakat untuk mengubah kami menjadi tim berbasis TDD / BDD yang produktif ... Yay!

Sekarang pertanyaannya adalah tentang kode yang sudah kita miliki: (1) Apakah masih baik-baik saja atau ide yang bagus untuk menghentikan sebagian besar pengembangan dan mulai menulis seluruh kasus uji yang mungkin dari awal, meskipun semuanya bekerja sepenuhnya OKE (belum!) ? Atau (2) lebih baik menunggu sesuatu yang buruk terjadi dan kemudian selama perbaikan menulis tes unit baru, atau (3) bahkan melupakan kode sebelumnya dan hanya menulis tes unit untuk kode baru saja dan menunda semuanya ke refactor besar berikutnya.

Ada beberapa artikel bagus dan terkait seperti ini . Saya masih tidak yakin apakah layak untuk berinvestasi dalam hal ini mengingat kami memiliki waktu yang sangat terbatas dan banyak proyek / pekerjaan lain menunggu kami.

Catatan : Pertanyaan ini menjelaskan / membayangkan situasi yang benar-benar aneh di tim pengembangan. Ini bukan tentang saya atau rekan saya; itu hanya situasi imajiner. Anda mungkin berpikir ini seharusnya tidak pernah terjadi atau manajer pengembangan bertanggung jawab atas kekacauan seperti itu! Tapi bagaimanapun, apa yang dilakukan sudah selesai. Jika memungkinkan, tolong jangan downvote hanya karena Anda pikir ini seharusnya tidak pernah terjadi.



6
Anda mungkin harus bersiap untuk tenggat waktu berikutnya tiba dan Anda tidak diizinkan untuk melakukan TDD lagi. Mungkin dengan memberi tahu siapa pun yang mengemudikan putaran terakhir pengembangan utang teknis mengapa itu bukan ide yang bagus.
jonrsharpe

1
@gnat Saya pikir ini bukan pertanyaan rangkap. Tim yang disebutkan itu tidak memiliki tes apa pun (bahkan tes integrasi)
Michel Gokan

1
@gnat pertanyaannya adalah: apa yang akan terjadi pada pengujian unit baru kami? Mereka mungkin tampak tidak lengkap, atau bahkan tidak berharga tanpa menulis semua tes unit untuk kode yang ditulis sebelumnya. Pertanyaan yang Anda sebutkan tidak mencakup masalah khusus ini.
Michel Gokan

1
Tidak mungkin untuk menulis semua test case yang mungkin. Ini hanya berguna untuk menulis semua kasus uji yang Anda pedulikan. Misalnya, jika Anda memerlukan fungsi yang akan menerima intnilai dan mengembalikan sesuatu yang spesifik, tidak mungkin untuk menulis unit-test untuk setiap intnilai yang mungkin , tetapi mungkin masuk akal untuk menguji beberapa nilai berguna yang mungkin menambah tiga kode, seperti angka negatif (termasuk minint), nol maxint,, dll. untuk memastikan bahwa beberapa kasus tepi tertutup.
Christopher Schultz

Jawaban:


36

Tidak ada proses pengembangan yang digerakkan oleh tes selama pengembangan karena tenggat waktu yang sangat ketat

Pernyataan ini sangat memprihatinkan. Bukan karena itu berarti Anda berkembang tanpa TDD atau karena Anda tidak menguji semuanya. Ini mengkhawatirkan, karena itu menunjukkan Anda berpikir TDD akan memperlambat Anda dan membuat Anda melewatkan tenggat waktu.

Selama Anda melihatnya dengan cara ini Anda tidak siap untuk TDD. TDD bukanlah sesuatu yang bisa Anda lakukan secara bertahap. Anda tahu cara melakukannya atau tidak. Jika Anda mencoba melakukannya di tengah jalan, Anda akan berhasil dan diri Anda terlihat buruk.

TDD adalah sesuatu yang harus Anda praktikkan di rumah terlebih dahulu. Belajarlah untuk melakukannya, karena ini membantu Anda membuat kode sekarang . Bukan karena seseorang menyuruhmu melakukannya. Bukan karena itu akan membantu ketika Anda melakukan perubahan nanti. Ketika itu menjadi sesuatu yang Anda lakukan karena Anda sedang terburu-buru maka Anda siap melakukannya secara profesional.

TDD adalah sesuatu yang dapat Anda lakukan di toko mana pun . Anda bahkan tidak perlu menyerahkan kode tes Anda. Anda dapat menyimpannya sendiri jika yang lain meremehkan tes. Ketika Anda melakukannya dengan benar, tes mempercepat pengembangan Anda, bahkan jika tidak ada orang lain yang menjalankannya.

Di sisi lain jika orang lain menyukai dan menjalankan tes Anda, Anda harus tetap ingat bahwa bahkan di toko TDD itu bukan tugas Anda untuk memeriksa tes. Ini untuk membuat kode produksi yang terbukti bekerja. Jika kebetulan bisa diuji, rapi.

Jika Anda berpikir manajemen harus percaya pada TDD atau bahwa sesama pembuat kode Anda harus mendukung tes Anda, maka Anda mengabaikan hal terbaik yang dilakukan TDD untuk Anda. Dengan cepat menunjukkan kepada Anda perbedaan antara apa yang Anda pikir kode Anda lakukan dan apa yang sebenarnya dilakukannya.

Jika Anda tidak dapat melihat bagaimana itu sendiri dapat membantu Anda memenuhi tenggat waktu lebih cepat maka Anda tidak siap untuk TDD di tempat kerja. Anda perlu berlatih di rumah.

Yang mengatakan, itu bagus ketika tim dapat menggunakan tes Anda untuk membantu mereka membaca kode produksi Anda dan ketika manajemen akan membeli alat TDD baru yang rumit.

Apakah ide yang baik untuk menulis semua kasus uji yang mungkin setelah mengubah tim menjadi TDD?

Terlepas dari apa yang dilakukan tim, tidak selalu merupakan ide yang baik untuk menulis semua kasus uji yang mungkin. Tulis kasus uji yang paling berguna. Cakupan kode 100% dikenakan biaya. Jangan abaikan hukum pengembalian yang semakin berkurang hanya karena menghakimi itu sulit.

Hemat energi pengujian Anda untuk logika bisnis yang menarik. Hal-hal yang membuat keputusan dan menegakkan kebijakan. Uji coba itu. Membosankan jelas kode lem struktural yang mudah dibaca yang hanya kabel barang bersama-sama tidak perlu pengujian hampir sama buruknya.

(1) Apakah masih baik-baik saja atau ide yang bagus untuk menghentikan sebagian besar pengembangan dan mulai menulis seluruh kasus uji yang mungkin dari awal, meskipun semuanya bekerja dengan baik OKE (belum!)? Atau

Ini adalah pemikiran "mari kita lakukan penulisan ulang lengkap". Ini menghancurkan pengetahuan yang sulit dimenangkan. Jangan meminta manajemen waktu untuk menulis tes. Cukup tulis tes. Setelah Anda tahu apa yang Anda lakukan, tes tidak akan memperlambat Anda.

(2) lebih baik menunggu sesuatu yang buruk terjadi dan kemudian selama perbaikan tulis unit test baru, atau

(3) bahkan melupakan kode sebelumnya dan hanya menulis unit test untuk kode baru saja dan menunda semuanya ke refactor besar berikutnya.

Saya akan menjawab 2 dan 3 dengan cara yang sama. Ketika Anda mengubah kode, untuk alasan apa pun, akan sangat bagus jika Anda bisa mengikuti tes. Jika kode ini lawas, saat ini tidak dapat menerima tes. Yang berarti sulit untuk mengujinya sebelum mengubahnya. Nah, karena Anda tetap mengubahnya, Anda dapat mengubahnya menjadi sesuatu yang dapat diuji dan mengujinya.

Itu opsi nuklir. Berisiko. Anda membuat perubahan tanpa tes. Ada beberapa trik kreatif untuk menguji kode lama sebelum Anda mengubahnya. Anda mencari apa yang disebut jahitan yang memungkinkan Anda mengubah perilaku kode Anda tanpa mengubah kode. Anda mengubah file konfigurasi, membuat file, apa pun yang diperlukan.

Michael Feathers memberi kami sebuah buku tentang ini: Bekerja Efektif dengan Legacy Code . Coba baca, dan Anda akan melihat bahwa Anda tidak perlu membakar semua yang lama untuk membuat sesuatu yang baru.


37
"Tes mempercepat perkembanganmu bahkan jika tidak ada orang lain yang menjalankannya." - Saya menemukan ini benar-benar salah. Ini mungkin bukan tempat untuk memulai diskusi tentang ini, tetapi pembaca harus ingat bahwa sudut pandang yang disajikan di sini tidak bulat.
Martin Ba

4
Sebenarnya, sering kali tes meningkatkan pengembangan Anda dalam jangka panjang dan agar TDD menjadi sangat efisien, semua orang perlu memercayainya, jika tidak, Anda akan menghabiskan setengah dari tim Anda untuk memperbaiki tes yang rusak oleh orang lain.
hspandher

13
"Anda pikir TDD akan memperlambat Anda dan membuat Anda melewatkan tenggat waktu." Saya berpikir bahwa mungkin adalah kasus. Tidak ada yang menggunakan TDD karena mereka mengharapkannya untuk membuat tenggat waktu pertama mereka dipenuhi lebih cepat. Manfaat nyata (setidaknya dalam estimasi saya) adalah dividen yang sedang berlangsung yang diuji bermain di masa depan, untuk menangkap regresi, dan untuk membangun kepercayaan dalam eksperimen yang aman. Saya pikir manfaat ini lebih besar daripada biaya awal untuk menulis tes, sebagian besar mungkin akan setuju, tetapi jika Anda harus memenuhi tenggat waktu yang ketat, Anda tidak punya pilihan.
Alexander - Reinstate Monica

1
Saya merasa analog dengan membeli rumah. Jika Anda memiliki lump sum untuk membayar rumah, Anda akan menghemat banyak bunga, dan itu akan bagus dalam jangka panjang. Tetapi jika Anda membutuhkan sebuah rumah segera ... maka Anda terpaksa mengambil pendekatan jangka pendek yang bersifat suboptimal jangka panjang
Alexander - Reinstate Monica

3
TDD = dapat = meningkatkan kinerja jika tes dan kode dikembangkan secara paralel, sementara fungsionalitasnya masih segar di pikiran pengembang. Ulasan kode akan memberi tahu Anda jika orang lain menganggap kode itu benar. Kasing uji akan memberi tahu Anda jika spesifikasi, sebagaimana tercantum dalam kasing uji, sedang diterapkan. Kalau tidak, yeah, TDD bisa menjadi hambatan terutama jika tidak ada spesifikasi fungsional dan penulis tes juga melakukan reverse engineering.
Julie di Austin

22

Apakah masih oke atau ide yang bagus untuk menghentikan sebagian besar pengembangan dan mulai menulis seluruh kasus uji yang mungkin dari awal [...]?

Diberi kode lawas 1 , tulis unit test dalam situasi berikut:

  • saat memperbaiki bug
  • saat refactoring
  • saat menambahkan fungsionalitas baru ke kode yang ada

Berguna sebagai unit test adalah, menciptakan lengkap tes unit suite untuk yang ada 1 basis kode mungkin bukan ide yang realistis. Kekuatan yang telah mendorong Anda untuk memenuhi tenggat waktu yang ketat. Mereka tidak memberi Anda waktu untuk membuat unit test yang memadai saat Anda berkembang. Apakah Anda pikir mereka akan memberi Anda waktu yang cukup untuk membuat tes untuk "program yang berfungsi"?

1 Kode lama adalah kode tanpa tes unit. Ini adalah definisi kode warisan TDD. Itu berlaku bahkan jika kode warisan baru dikirim [bahkan jika tinta belum kering].


Tetapi kemudian pengujian unit baru kami untuk fitur-fitur baru mungkin tampak tidak lengkap, atau bahkan tidak berharga tanpa uji unit yang hilang. Bukan?
Michel Gokan

7
(1) Tidak berharga? Tentu tidak. Paling tidak, mereka menguji fitur baru. Lain kali seseorang ingin memodifikasi fitur ini, mereka akan menggunakan kembali banyak tes yang ada. (2) Tidak lengkap? Mungkin tidak. Jika Anda juga membuat tes unit yang menguji fungsionalitas lawas yang menjadi sandaran fitur baru, maka tes tersebut mungkin cukup lengkap untuk tujuan praktis. Dengan kata lain, buat tes unit tambahan yang menembus fungsi legacy. Menembus sampai kedalaman berapa? Itu tergantung pada arsitektur program, sumber daya yang tersedia, dukungan kelembagaan.
Nick Alexeev

Kelemahan dari "menulis tes ketika Anda tersandung ketika membutuhkannya" adalah bahwa ada peningkatan risiko berakhir dengan tambal sulam tes yang ditulis oleh pengembang yang berbeda dengan ide yang berbeda. Saya tidak mengatakan jawaban ini salah, tetapi memang membutuhkan tangan yang kuat yang menjaga kualitas dan gaya seragam tes.
Flater

4
@Feragam air memberikan kenyamanan palsu. Saya ingin tes yang membuat kode produksi mudah dibaca. Bukan tes yang semuanya terlihat sama. Saya akan memaafkan mencampur kerangka kerja pengujian yang berbeda jika membuatnya lebih mudah untuk memahami apa yang dilakukan kode produksi.
candied_orange

2
@Flater Saya tidak menegaskan kode produksi yang jelek. Saya menegaskan bahwa tujuan dari tes ini adalah membuat kode produksi dapat dibaca. Saya dengan senang hati akan menerima sejumlah besar pengujian yang membuat kode produksi lebih mudah dibaca. Berhati-hatilah untuk menjadikan keseragaman tujuan itu sendiri. Keterbacaan adalah raja.
candied_orange

12

Dalam pengalaman saya, tes tidak perlu cakupan total untuk membantu. Alih-alih, Anda mulai menuai berbagai jenis manfaat saat cakupan meningkat:

  • cakupan lebih dari 30% (alias beberapa tes integrasi): jika tes Anda gagal, ada sesuatu yang sangat rusak (atau tes Anda tidak jelas). Syukurlah tes ini memberi tahu Anda dengan cepat! Namun rilis masih akan membutuhkan pengujian manual yang ekstensif.
  • cakupan lebih dari 90% (alias sebagian besar komponen memiliki tes unit dangkal): jika tes Anda lulus, sebagian besar perangkat lunak kemungkinan baik-baik saja. Bagian yang belum diuji adalah kasus tepi, yang baik untuk perangkat lunak yang tidak kritis. Namun rilis masih membutuhkan beberapa pengujian manual.
  • cakupan fungsi / pernyataan / cabang / persyaratan yang sangat tinggi: Anda menjalani mimpi TDD / BDD , dan tes Anda adalah cerminan yang tepat dari fungsi perangkat lunak Anda. Anda dapat refactor dengan kepercayaan tinggi, termasuk perubahan arsitektur skala besar. Jika tes lulus, perangkat lunak Anda hampir siap dirilis; hanya diperlukan beberapa pengujian asap manual.

Yang benar adalah, jika Anda tidak memulai dengan BDD Anda tidak akan pernah sampai di sana, karena pekerjaan yang diperlukan untuk menguji setelah pengkodean hanya berlebihan. Masalahnya bukan menulis tes, tetapi lebih menyadari persyaratan aktual (daripada detail implementasi insidental) dan mampu merancang perangkat lunak dengan cara yang fungsional dan mudah untuk diuji. Saat Anda menulis tes pertama atau bersama-sama dengan kode, ini praktis gratis.

Karena fitur baru memerlukan pengujian, tetapi pengujian memerlukan perubahan desain, tetapi refactoring juga memerlukan pengujian, Anda memiliki sedikit masalah ayam dan telur. Ketika perangkat lunak Anda merayap mendekati cakupan yang layak, Anda harus melakukan beberapa refactoring dengan hati-hati pada bagian-bagian kode tempat fitur baru muncul, hanya untuk membuat fitur baru dapat diuji. Ini akan banyak memperlambat Anda - awalnya. Tetapi dengan hanya melakukan refactoring dan menguji bagian-bagian di mana pengembangan baru diperlukan, tes juga fokus pada area di mana mereka paling dibutuhkan. Kode yang stabil dapat dilanjutkan tanpa tes: jika buggy, Anda harus mengubahnya.

Saat Anda mencoba beradaptasi dengan TDD, metrik yang lebih baik daripada cakupan total proyek akan menjadi cakupan uji di bagian yang sedang diubah. Cakupan ini harus sangat tinggi sejak awal, meskipun tidak layak untuk menguji semua bagian kode yang terkena dampak refactoring. Juga, Anda menuai sebagian besar manfaat dari cakupan uji tinggi dalam komponen yang diuji. Itu tidak sempurna, tetapi masih cukup bagus.

Perhatikan bahwa meskipun tes unit tampaknya umum, dimulai dengan bagian terkecil bukanlah strategi yang cocok untuk mendapatkan perangkat lunak warisan yang sedang diuji. Anda akan ingin memulai dengan tes integrasi yang menjalankan sebagian besar perangkat lunak sekaligus.

Misalnya saya merasa berguna untuk mengekstrak kasus uji integrasi dari file log dunia nyata. Tentu saja menjalankan tes semacam itu bisa memakan banyak waktu, itulah sebabnya Anda mungkin ingin mengatur server otomatis yang menjalankan tes secara teratur (misalnya server Jenkins yang dipicu oleh komitmen). Biaya pengaturan dan pemeliharaan server seperti itu sangat kecil dibandingkan dengan tidak menjalankan tes secara teratur, dengan ketentuan bahwa setiap kegagalan tes benar-benar diperbaiki dengan cepat.


"cakupan lebih dari 90% (alias sebagian besar komponen memiliki tes unit dangkal): jika tes Anda lulus, sebagian besar perangkat lunak kemungkinan besar baik. Bagian yang belum diuji adalah kasus tepi, yang baik untuk perangkat lunak tidak kritis ." Ini kedengarannya agak aneh bagi saya, FWIW, saya lebih suka memiliki cakupan 30% yang sebagian besar terdiri dari kasus tepi daripada cakupan 90% yang seluruhnya terdiri dari perilaku jalur yang diharapkan (yang mudah dilakukan oleh penguji manual); Saya merekomendasikan untuk berpikir "di luar kotak" ketika menulis tes dan mendasarkannya pada kasus uji (tidak biasa) yang ditemukan secara manual bila memungkinkan.
jrh

5

Jangan menulis tes untuk kode yang ada. Itu tidak layak.

Apa yang Anda buat sudah agak diuji dengan cara yang benar-benar informal - Anda mencobanya dengan tangan terus-menerus, orang-orang melakukan beberapa pengujian yang tidak diautomasi, sedang digunakan sekarang. Itu berarti Anda tidak akan menemukan banyak bug .

Yang tersisa adalah bug yang tidak Anda pikirkan. Tapi itu persis yang Anda tidak akan berpikir untuk menulis unit test untuk keduanya, jadi Anda mungkin masih tidak akan menemukannya.

Juga, alasan untuk TDD adalah membuat Anda berpikir tentang apa persyaratan sebenarnya dari sedikit kode sebelum menulisnya. Dengan cara apa pun yang berbeda, Anda sudah melakukannya.

Sementara itu, masih banyak pekerjaan untuk menulis tes ini seperti menulisnya sebelumnya. Akan memakan banyak waktu, untuk sedikit manfaat.

Dan sangat membosankan untuk menulis banyak tes tanpa ada kode di antaranya dan hampir tidak menemukan bug. Jika Anda mulai melakukan ini, orang yang baru mengenal TDD akan membencinya .

Singkatnya, devs akan membencinya dan manajer akan melihatnya mahal, sementara tidak banyak bug ditemukan. Anda tidak akan pernah sampai ke bagian TDD yang sebenarnya.

Gunakan pada hal-hal yang ingin Anda ubah, sebagai bagian normal dari proses.


1
Saya sangat tidak setuju dengan "Jangan menulis tes untuk kode yang ada. Itu tidak layak." Jika kode berfungsi dengan baik, tes mungkin merupakan satu-satunya spesifikasi yang ada. Dan jika kode sedang dalam pemeliharaan, menambahkan tes adalah satu-satunya cara untuk memastikan fungsi-fungsi yang berfungsi tidak rusak oleh perubahan yang tampaknya tidak terkait.
Julie di Austin

3
@JulieinAustin: Di sisi lain, tanpa spec, Anda tidak tahu persis apa yang seharusnya dilakukan oleh kode. Dan jika Anda belum tahu kode apa yang seharusnya dilakukan, Anda dapat menulis tes yang tidak berguna - atau lebih buruk, tes yang menyesatkan yang secara halus mengubah spesifikasi - dan sekarang diperlukan perilaku tidak disengaja dan / atau salah.
cao

2

Tes adalah sarana untuk mengkomunikasikan pemahaman.

Karena itu hanya tulis tes untuk apa yang Anda pahami harus benar.

Anda hanya bisa memahami apa yang seharusnya benar ketika Anda bekerja dengannya.

Karena itu hanya tulis tes untuk kode yang Anda kerjakan.

Ketika Anda bekerja dengan kode Anda akan belajar.

Karena itu tulis dan tulis ulang tes untuk menangkap apa yang telah Anda pelajari.

Bilas dan ulangi.

Biarkan alat cakupan kode dijalankan dengan tes Anda, dan hanya menerima komitmen ke jalur utama yang tidak mengurangi cakupan. Akhirnya Anda akan mencapai tingkat cakupan yang tinggi.

Jika Anda belum bekerja dengan kode tersebut untuk sementara waktu, keputusan bisnis perlu dibuat. Sekarang sangat mungkin warisan sehingga tidak ada seorang pun di tim Anda yang tahu cara bekerja dengannya. Mungkin memiliki perpustakaan / kompiler / dokumentasi yang sudah ketinggalan zaman yang merupakan tanggung jawab besar dalam segala hal.

Dua pilihan:

  1. Investasikan waktu untuk membacanya, belajar darinya, menulis tes untuk itu, dan refactor. Kumpulan perubahan kecil dengan rilis yang sering.
  2. Temukan cara untuk membuang perangkat lunak itu. Anda tidak dapat membuat modifikasi saat diminta.

0

(1) Apakah masih baik-baik saja atau ide yang bagus untuk menghentikan sebagian besar pengembangan dan mulai menulis seluruh kasus uji yang mungkin dari awal, meskipun semuanya bekerja dengan baik OKE (belum!)?
(2) lebih baik menunggu sesuatu yang buruk terjadi dan kemudian selama perbaikan tulis unit test baru

Salah satu tujuan utama tes adalah untuk memastikan bahwa perubahan tidak merusak apa pun. Ini adalah proses tiga langkah:

  1. Pastikan bahwa tes berhasil
  2. Buat Anda berubah
  3. Konfirmasikan bahwa tes masih berhasil

Ini berarti bahwa Anda perlu melakukan tes sebelum Anda benar-benar mengubah sesuatu. Jika Anda memilih jalur kedua, itu artinya Anda harus memaksa pengembang Anda untuk menulis tes bahkan sebelum mereka menyentuh kode. Dan saya sangat curiga bahwa ketika sudah dihadapkan dengan perubahan dunia nyata, para pengembang tidak akan memberikan unit tes perhatian yang layak mereka dapatkan.

Jadi saya menyarankan untuk membagi tugas penulisan tes dan perubahan untuk menghindari pengembang mengorbankan kualitas satu untuk yang lain.

meskipun semuanya bekerja sepenuhnya OKE (belum!)?

Hanya untuk menunjukkan ini secara khusus, itu adalah kesalahpahaman umum bahwa Anda hanya perlu tes ketika kode tidak berfungsi. Anda memerlukan tes saat kode berfungsi juga, misalnya untuk membuktikan kepada seseorang bahwa [bug yang baru muncul] bukan karena bagian Anda karena tes masih berjalan.
Mengonfirmasi bahwa semuanya masih berfungsi seperti sebelumnya adalah manfaat penting dari pengujian yang Anda abaikan saat Anda menyiratkan bahwa Anda tidak memerlukan pengujian saat kode berfungsi.

(3) bahkan melupakan kode sebelumnya dan hanya menulis unit test untuk kode baru saja dan menunda semuanya ke refactor besar berikutnya

Idealnya, semua kode sumber yang ada sekarang harus mendapatkan tes unit. Namun, ada argumen yang masuk akal bahwa waktu dan upaya (dan biaya) yang diperlukan untuk melakukannya sama sekali tidak relevan untuk proyek-proyek tertentu.
Misalnya, aplikasi yang tidak lagi dikembangkan dan tidak diharapkan untuk diubah lagi (mis. Klien tidak lagi menggunakannya, atau klien bukan lagi klien), Anda dapat berargumen bahwa tidak relevan untuk menguji kode ini lagi .

Namun, itu tidak jelas memotong di mana Anda menarik garis. Ini adalah sesuatu yang perlu dilihat perusahaan dalam analisis manfaat biaya. Tes menulis membutuhkan waktu dan tenaga, tetapi apakah mereka mengharapkan pengembangan di masa depan pada aplikasi itu? Apakah keuntungan dari memiliki unit test lebih besar daripada biaya penulisan mereka?

Ini bukan keputusan yang dapat Anda (sebagai pengembang) buat. Paling-paling, Anda dapat menawarkan perkiraan waktu yang dibutuhkan untuk melaksanakan tes pada proyek tertentu, dan terserah manajemen untuk memutuskan apakah ada harapan yang cukup untuk benar-benar perlu mempertahankan / mengembangkan proyek.

dan menunda semuanya ke refactor besar berikutnya

Jika refactor utama berikutnya diberikan, maka Anda memang perlu menulis tes.

Tetapi jangan menundanya sampai Anda dihadapkan dengan perubahan besar. Poin awal saya (tidak menggabungkan penulisan tes dan memperbarui kode) masih ada, tapi saya ingin menambahkan poin kedua di sini: pengembang Anda saat ini mengetahui jalannya proyek lebih baik daripada dalam enam bulan jika mereka menghabiskan waktu bekerja pada proyek lain. Memanfaatkan periode waktu di mana para pengembang sudah melakukan pemanasan dan tidak perlu memikirkan bagaimana hal-hal bekerja lagi di masa depan.


0

Dua sen saya:

Tunggu hingga peningkatan teknis utama ke sistem dan tulis tesnya lalu ... secara resmi dengan dukungan bisnis.

Atau, katakanlah Anda adalah toko SCRUM, beban kerja Anda diwakili oleh kapasitas dan Anda dapat mengalokasikan% dari itu untuk pengujian unit, tetapi ...

Mengatakan Anda akan kembali dan menulis tes itu naif, apa yang sebenarnya akan Anda lakukan adalah menulis tes, refactor, dan menulis lebih banyak tes setelah refactor membuat kode lebih dapat diuji, itulah sebabnya yang terbaik untuk memulai dengan tes seperti yang Anda sudah ketahui, dan ...

Yang terbaik bagi penulis asli untuk menulis tes dan refactor kode yang mereka tulis sebelumnya, itu tidak ideal, tetapi dari pengalaman Anda ingin refactor membuat kode lebih baik tidak lebih buruk.

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.