Haruskah saya menulis tes ketika saya bisa membuktikan kebenaran kode?

8

Orang mengatakan bahwa "berbicara tentang TDD tidak berhasil, jika Anda ingin meyakinkan seseorang untuk TDD, tunjukkan hasil". Namun, saya sudah mendapatkan hasil yang bagus tanpa TDD. Menunjukkan kepada saya bahwa orang yang menggunakan TDD mendapatkan hasil yang baik tidak akan meyakinkan, saya ingin melihat bahwa orang yang menulis TDD dan bukan-TDD mendapatkan hasil yang lebih baik dengan TDD.

Terlepas dari semua ini, saya tertarik untuk mencoba TDD. Namun saya tidak yakin saya akan mendapatkan apa pun dari ini. Jika terbukti bermanfaat, saya akan mencoba mendorongnya ke seluruh tim saya.

Pertanyaan utama saya adalah ini: Apakah TDD melayani tujuan apa pun untuk kode, jika saya sudah dapat membuktikan kebenaran kode?

Jelas, tidak ada yang peluru. Bukti Anda mungkin salah karena Anda melewatkan detail, dan pengujian Anda mungkin gagal menemukan bug yang gagal Anda uji. Pada akhirnya, kita manusia, tidak ada yang bisa membuat kode bebas bug 100% selamanya. Kami hanya bisa berusaha sedekat mungkin.

Namun, apakah TDD benar-benar menghemat waktu pada kode yang kebenarannya telah terbukti? yaitu kode yang, di mesin negara di mana kode beroperasi, semua status yang mungkin valid dan rentangnya diakui oleh pengembang, semua diperhitungkan, dan kode tersebut dirancang dalam pemeriksaan kesalahan gaya daftar putih yang melewati setiap pengecualian untuk penangan atas untuk memastikan tidak ada kebocoran yang tidak terduga -> tanpa keduanya menampilkan pesan (sesuai alasan-) kepada klien dan mengirim pemberitahuan log ke admin.

Jawaban dengan contoh nyata akan lebih baik.

Beberapa klarifikasi:

Pertanyaan ini bukan tentang apakah Anda dapat membuktikan kebenaran kode atau tidak. Mari kita asumsikan secara default bahwa tidak semua kode dapat dibuktikan benar dalam jangka waktu yang masuk akal, tetapi beberapa kode dapat. Misalnya, sangat mudah untuk membuktikan kebenaran modul FizzBuzz. Tidak mudah untuk layanan sinkronisasi data berbasis cloud.
Dalam batasan ini, pertanyaan diajukan sebagai berikut: Mulai dengan asumsi bahwa basis kode dibagi menjadi 2 bagian: [I] bagian yang telah terbukti benar [II] bagian yang belum terbukti benar, tetapi diuji secara manual untuk bekerja.
Saya ingin menerapkan praktik TDD ke basis kode ini yang tidak memilikinya hingga sekarang. Pertanyaannya adalah sebagai berikut: haruskah TDD diterapkan ke setiap modul tunggal, atau apakah cukup untuk menerapkannya hanya pada modul yang tidak terbukti benar?
"Terbukti benar" berarti Anda dapat mempertimbangkan modul ini sepenuhnya fungsional-gaya, yaitu, ia tidak bergantung pada keadaan global atau luar di luar itu sendiri, dan sepenuhnya memiliki API sendiri untuk I / O yang harus diikuti oleh modul lain yang berinteraksi dengannya. . Tidak mungkin untuk "memecah modul ini" dengan mengubah kode di luar modul, paling buruk Anda dapat menyalahgunakannya dan mendapatkan pesan kesalahan yang diformat dikembalikan kepada Anda.
Jelas, setiap aturan memiliki pengecualian, bug penyusun dalam versi penyusun baru dapat memperkenalkan bug pada modul ini, tetapi bug yang sama dapat diperkenalkan ke pengujian yang mengujinya dan menghasilkan rasa aman yang salah dari pengujian yang tidak lagi berfungsi sebagaimana dimaksud. Intinya adalah bahwa tes bukan solusi ajaib, mereka adalah lapisan perlindungan lain, dan pertanyaan ini membahas masalah apakah lapisan perlindungan ini sepadan dengan usaha dalam kasus spesifik modul yang terbukti benar (asumsikan bahwa memang).

tdd

— Kylee
sumber

10

Membuktikan "kebenaran kode" mungkin menjadi lebih sulit menurut Anda.

— πάντα ῥεῖ

34

Sementara saya menikmati belajar tentang tempat kerja Anda dan riwayat pekerjaan Anda, saya hampir berhenti membaca beberapa kali karena, terkadang yang benar-benar penting adalah, sebagai cara memaksimalkan hasil Anda, dan, untuk menjaga perhatian pembaca Anda sehingga mereka dapat, dalam upaya untuk memperkuat pengetahuan Anda serta masyarakat, membantu Anda, Anda harus ... mencapai intinya . Silakan pertimbangkan untuk mempersingkat pertanyaan Anda ke poin yang paling menonjol.

— MetaFight

10

Apa yang Anda gambarkan bukanlah proses "membuktikan kebenaran" kode. Proses semacam itu sangat berbeda. Juga, saya merasa sulit untuk menerima bahwa Anda dapat membangun kode dengan cara yang dapat "dibuktikan benar" hanya dengan melihatnya. Saya melihat banyak kode yang tampak sepele dan "benar", hanya untuk benar-benar hancur ketika diuji otomatis.

— Euphoric

8

"Waspadalah terhadap bug dalam kode di atas; Saya hanya membuktikannya benar, tidak mencobanya." -Donald Knuth.

— Neil

6

Pertanyaan Anda tidak masuk akal. TDD berarti bahwa tes mendorong pengembangan. Dengan kata lain, Anda tidak memiliki desain, tidak ada arsitektur, tidak ada kode, kecuali Anda memiliki tes untuk itu. Jadi, bagaimana di dunia Anda "menerapkan TDD ke kode yang telah terbukti benar" ketika dengan definisi TDD, tidak ada kode untuk membuktikan benar ?

— Jörg W Mittag

20

Iya.

Bukti baik-baik saja ketika mereka tersedia, tetapi bahkan pada saat terbaik mereka hanya membuktikan bahwa sedikit kode akan bekerja seperti yang diharapkan (untuk semua input? Akuntansi untuk gangguan di tengah operasi apa pun? Bagaimana dengan kehabisan memori? ? kegagalan disk? kegagalan jaringan?)

Apa yang terjadi ketika itu berubah?

Tes sangat bagus karena berfungsi sebagai kontrak tersirat tentang apa yang harus dilakukan kode. Mereka menyediakan beberapa perancah sehingga magang baru Anda dapat masuk dan melakukan perubahan dengan tingkat kepercayaan tertentu. Semua melalui hasil yang cepat dan jelas: lulus atau gagal.

Dan sejujurnya, saya bisa melatih magang untuk menulis tes unit yang layak dalam beberapa bulan. Saya ragu bahwa siapa pun di tim saya (termasuk saya) dapat membuat bukti yang menjamin sesuatu yang berarti untuk kode non-sepele; apalagi melakukannya dengan cepat dan akurat.

— Telastyn
sumber

Kode yang sama yang akan non-sepele untuk dibuktikan juga tidak-sepele untuk diuji. Kegagalan jaringan atau kegagalan disk dapat memiliki banyak bentuk, bagaimana Anda bisa yakin bahwa pengujian Anda mencakup setiap skenario yang mungkin terjadi? Mereka kemungkinan besar akan mencakup setiap skenario tunggal yang dapat Anda pikirkan, tetapi tidak harus setiap skenario tunggal dalam kehidupan nyata. Anda tidak bisa begitu saja berasumsi bahwa setiap perubahan tidak akan melanggar hanya karena Anda memiliki tes di tempat. Ini hanyalah lapisan perlindungan lain. Tes itu penting, tetapi itu bukan peluru perak.

— Kylee

6

@Kylee - jangan tersinggung, tetapi Anda tampaknya terlalu meremehkan upaya dan keterampilan yang diperlukan untuk melakukan bukti kebenaran (atau terlalu melebih-lebihkan upaya dan keterampilan yang diperlukan untuk menyatukan beberapa tes otomatis).

— Telastyn

Mungkin Anda benar, dan kemungkinan besar saya melebih-lebihkan upaya menyusun tes karena tidak berpengalaman dengan itu (jujur, itu kurang "tes menyusun" yang saya khawatirkan, dan lebih banyak tentang benar-benar menjalankan tes. Untuk proyek-proyek besar & cepat berubah, itu sendiri bukanlah waktu yang dapat diabaikan). Bagaimanapun, ini tidak ada hubungannya dengan pertanyaan. Pertanyaannya dengan jelas menyatakan, anggap Anda memiliki kode yang sudah terbukti benar, apakah masih ada titik untuk menulis tes unit untuk itu?

— Kylee

1

For large & rapidly changing projectssemakin rentan untuk berubah semakin penting adalah tes, karena kode perubahan memiliki lebih banyak peluang untuk gagal karena bug baru atau perilaku tak terduga, daripada kode yang nyaris tidak berubah. Ini masalah probabilitas. Bahkan jika itu tidak sering berubah, setelah beberapa saat pengetahuan yang diperoleh selama pengembangan bisa hilang atau terlupakan. Tes juga merupakan pengetahuan yang terwujud, yang dapat mengurangi, secara signifikan, kurva pembelajaran. Apakah pengujian kode memakan waktu? Iya. Apakah itu membuat proyek lebih mahal? Tidak, dalam jangka panjang membuatnya lebih murah .

— Laiv

3

@Kylee Bahkan jika Anda dapat membuktikan bahwa sepotong kode sudah benar, paling banter Anda akan berada dalam situasi bahwa tidak ada seorang pun yang diizinkan untuk mengubah kode itu atau menambahkan fitur ke dalamnya; untuk melakukannya akan membatalkan bukti Anda. Seperti yang sudah disorot dalam jawaban ini, tes memungkinkan Anda untuk mengubah kode Anda dengan percaya diri. Bahkan jika orang yang mengubahnya itu adalah magang yang tidak berpengalaman. Ngomong-ngomong, bahkan jika beberapa blok kode 100% benar tidak berarti Anda tidak perlu mengubahnya (misalnya untuk menambah fitur baru yang dibutuhkan oleh pelanggan atau untuk memenuhi beberapa kendala dunia nyata yang tidak dipertimbangkan dalam bukti Anda).

— Brandin

5

Kami tidak tahu. Kami tidak dapat menjawab pertanyaan Anda.

Sementara Anda menghabiskan banyak waktu untuk menjelaskan proses yang Anda miliki sekarang tampaknya bekerja untuk kepuasan semua orang, Anda memberi tahu kami hanya sepotong kecil dari apa yang sebenarnya terjadi.

Dari pengalaman saya, apa yang Anda gambarkan adalah kelangkaan yang ekstrem dan saya ragu bahwa sebenarnya proses dan pendekatan Anda terhadap pengkodean yang sebenarnya menyebabkan jumlah bug yang rendah dalam aplikasi Anda. Mungkin ada banyak faktor lain yang memengaruhi aplikasi Anda dan Anda tidak memberi tahu kami tentang faktor-faktor itu.

Jadi kami tidak tahu, dalam menghadapi tidak mengetahui lingkungan pengembangan dan budaya Anda, apakah TDD akan membantu Anda atau tidak. Dan kita bisa menghabiskan waktu berhari-hari untuk berdiskusi dan berdebat tentang hal itu.

Hanya ada satu rekomendasi yang dapat kami berikan kepada Anda: cobalah. Percobaan. Pelajari itu. Saya tahu Anda berusaha menghabiskan paling sedikit upaya untuk memutuskan, tetapi itu tidak mungkin. Jika Anda benar-benar ingin tahu apakah TDD akan berfungsi dalam konteks Anda, satu-satunya cara untuk mengetahuinya adalah dengan benar-benar melakukan TDD. Jika Anda benar-benar mempelajarinya dan menerapkannya pada aplikasi Anda, Anda dapat membandingkannya dengan proses non-TDD Anda. Mungkin TDD sebenarnya memiliki kelebihan dan Anda memutuskan untuk menyimpannya. Atau bisa keluar bahwa TDD tidak membawa sesuatu yang baru dan hanya memperlambat Anda. Dalam hal ini, Anda dapat kembali ke proses sebelumnya.

— Euforia
sumber

5

Tujuan utama dari pengujian (unit) adalah menjaga kode, memastikan kode tidak pecah tanpa disadari karena perubahan di kemudian hari. Ketika kode pertama kali ditulis, itu akan mendapatkan banyak perhatian dan akan diteliti. Dan Anda mungkin memiliki beberapa sistem superior untuk itu.

Enam bulan kemudian, ketika orang lain mengerjakan sesuatu yang tampaknya tidak berhubungan, itu mungkin rusak dan super-duper-code-correctver-prover Anda tidak akan menyadarinya. Tes otomatis akan.

— Martin Maat
sumber

1

Ini adalah sesuatu yang terlalu sering diabaikan. Ya, ada rasa sakit untuk dilalui untuk memastikan kode memiliki unit test sekarang. Tetapi ini akan membayar sendiri berkali-kali lipat ketika seorang junior dev melakukan perubahan sederhana dan unit test segera menunjukkan bahwa mereka telah merusak sesuatu yang lain. Saya sudah menjadi junior dev dekade lalu yang telah merusak sesuatu dan seluruh rilis telah ditunda. Sementara kolega saya sangat toleran pada saat itu dan mendukung saya ketika manajer mulai melompat-lompat, seluruh skenario dapat, jika ditinjau, dihindari jika unit test sudah ada.

— Robbie Dee

5

Saya ingin menerapkan praktik TDD ke basis kode ini yang tidak memilikinya hingga sekarang.

Ini adalah cara tersulit untuk mempelajari TDD. Semakin lama Anda menguji, semakin banyak biayanya untuk menulis tes dan semakin sedikit Anda keluar dari menulisnya.

Saya tidak mengatakan tidak mungkin untuk retrofit tes ke basis kode yang ada. Saya mengatakan hal itu tidak akan membuat siapa pun menjadi penganut TDD. Ini kerja keras.

Sebenarnya lebih baik berlatih TDD pertama kali pada sesuatu yang baru dan di rumah. Dengan begitu Anda belajar ritme yang sebenarnya. Lakukan ini dengan benar dan Anda akan ketagihan.

Pertanyaannya menanyakan hal berikut: apakah TDD harus diterapkan ke setiap modul tunggal,

Itu adalah pemikiran struktural. Anda seharusnya tidak mengatakan hal-hal seperti menguji setiap fungsi, atau kelas, atau modul. Batas-batas itu tidak penting untuk pengujian dan mereka harus dapat berubah pula. TDD adalah tentang membangun kebutuhan perilaku yang dapat diuji dan tidak peduli bagaimana itu terpenuhi. Kalau bukan kita tidak bisa refactor.

atau apakah itu cukup untuk menerapkannya hanya pada modul yang tidak terbukti benar?

Cukup menerapkannya di tempat Anda menemukan kebutuhannya. Saya akan mulai dengan kode baru. Anda akan mendapatkan jauh lebih banyak dari pengujian awal daripada dari terlambat. Jangan lakukan ini di tempat kerja sampai Anda sudah cukup berlatih untuk menguasainya di rumah.

Ketika Anda telah menunjukkan TDD efektif dengan kode baru di tempat kerja dan merasa cukup percaya diri untuk mengambil kode lama saya akan mulai dengan kode yang terbukti. Alasannya adalah karena Anda akan dapat langsung melihat jika tes yang Anda tulis mengambil kode ke arah yang baik.

Pertanyaan utama saya adalah ini: Apakah TDD melayani tujuan apa pun untuk kode, jika saya sudah dapat membuktikan kebenaran kode?

Tes tidak hanya membuktikan kebenaran. Mereka menunjukkan niat. Mereka menunjukkan apa yang dibutuhkan. Mereka menunjukkan jalan untuk berubah. Tes yang bagus mengatakan ada beberapa cara untuk menulis kode ini dan mendapatkan yang Anda inginkan. Mereka membantu pembuat kode baru melihat apa yang dapat mereka lakukan tanpa merusak segalanya.

Hanya sekali Anda memilikinya turun Anda harus berjalan ke kode yang belum terbukti.

Sebuah peringatan terhadap orang-orang fanatik: Anda terdengar seperti Anda telah mencapai kesuksesan dan karena itu tidak akan mungkin melompat lebih dulu. Tetapi orang-orang lain yang ingin membuktikan diri mereka tidak akan begitu tertutup TDD bisa berlebihan. Sangat luar biasa mudah untuk membuat serangkaian pengujian yang benar-benar merugikan refactoring karena mereka mengunci hal-hal yang sepele dan tidak berarti. Bagaimana ini bisa terjadi? Karena orang yang ingin memamerkan tes hanya menulis tes dan tidak pernah refactor. Larutan? Buat mereka refactor. Buat mereka berurusan dengan perubahan fitur. Lebih cepat lebih baik. Itu akan menunjukkan kepada Anda tes yang tidak berguna dengan cepat. Anda membuktikan fleksibilitas dengan melenturkan.

Peringatan terhadap kategorisasi struktural: Beberapa orang akan bersikeras bahwa kelas adalah unit. Beberapa akan menyebut tes apa pun dengan dua kelas sebagai tes integrasi. Beberapa akan bersikeras bahwa Anda tidak dapat melewati batas x dan menyebutnya sebagai unit test. Daripada peduli tentang semua itu, saya menyarankan Anda untuk peduli tentang bagaimana tes Anda berperilaku. Bisakah itu berjalan dalam sepersekian detik? Apakah bisa dijalankan secara paralel dengan tes lain (efek samping gratis)? Bisakah itu dijalankan tanpa memulai atau mengedit hal lain untuk memenuhi dependensi dan prasyarat? Saya menempatkan pertimbangan ini di depan jika berbicara dengan DB, sistem file, atau jaringan. Mengapa? Karena tiga yang terakhir ini hanya masalah karena mereka menyebabkan masalah lain. Kelompokkan tes Anda bersama-sama berdasarkan cara Anda mengharapkannya berperilaku. Bukan batas yang kebetulan mereka lewati. Maka Anda tahu apa yang dapat Anda harapkan dari setiap test suite.

Saya telah melihat orang mengatakan mereka tidak ingin menggunakan TDD karena terlalu banyak overhead, dan pendukung TDD mempertahankannya dengan mengatakan bahwa setelah Anda terbiasa menulis TDD sepanjang waktu tidak ada banyak overhead.

Pertanyaan itu sudah ada jawabannya di sini .

— candied_orange
sumber

1

Pengembangan Test Driven lebih tentang prototyping dan brainstorming API, daripada pengujian. Tes yang dibuat seringkali berkualitas buruk dan akhirnya harus dibuang. Keuntungan utama TDD adalah menentukan bagaimana API akan digunakan, sebelum menulis implementasi API. Keuntungan ini juga dapat diperoleh dengan cara lain, misalnya dengan menulis dokumentasi API sebelum implementasi.

Bukti kebenaran selalu lebih berharga daripada tes. Tes tidak membuktikan apa pun. Namun, untuk menggunakan bukti kebenaran secara produktif, akan membantu untuk memiliki pemeriksa bukti otomatis, dan Anda perlu bekerja menggunakan beberapa jenis kontrak (desain berdasarkan kontrak atau desain berbasis kontrak).

Di masa lalu, ketika bekerja pada bagian kode yang kritis, saya akan mencoba bukti kebenaran manual. Bahkan bukti informal lebih berharga daripada tes otomatis. Tetapi Anda masih membutuhkan tes, kecuali jika Anda dapat mengotomatiskan bukti Anda, karena orang-orang akan merusak kode Anda di masa depan.

Tes otomatis tidak menyiratkan TDD.

— Frank Hileman
sumber

Brainstorming API dan desain berdasarkan kontrak sudah merupakan cara saya mendekati masalah, jadi saya ingin mengatakan bahwa saya menyukai jawaban Anda, tetapi sumber lain mengatakan "Dalam pengembangan yang didorong oleh tes, setiap fitur baru dimulai dengan menulis tes". Anda mengatakan hal-hal yang saya setujui, tetapi tidak meyakinkan saya untuk menggunakan pendekatan TDD. "Tes otomatis tidak menyiratkan TDD", ok, tapi kemudian, apa yang disiratkan oleh TDD, dibandingkan dengan hanya mengikuti praktik terbaik umum?

— Kylee

1

Meskipun saya setuju bahwa TDD sering melibatkan brainstorming API, IMO, ini terkadang merupakan hal yang buruk . API seharusnya tidak dirancang (harus) untuk dapat diuji, API harus dirancang untuk digunakan dengan lancar oleh klien Anda, dan masuk akal untuk kelas / kode yang terlibat. Terlalu sering saya melihat penulis tes mengatakan "mari kita tambahkan di String getSomeValue()sini sehingga kita bisa mengujinya" ketika itu tidak masuk akal untuk desain keseluruhan. Tentu, Anda bisa menghapus fungsi itu nanti, tetapi, dalam pengalaman saya, itu jarang terjadi.

— user949300

1

@ user949300, Ada tumpang tindih besar antara merancang API yang dapat diuji dan yang dirancang untuk digunakan dengan lancar oleh klien Anda. Menambahkan kode yang tidak perlu demi pengujian menunjukkan Anda memiliki desain yang buruk. Terlalu sering, penulis API lupa tentang men-debug apa yang salah dengan API. Menulis sesuatu yang dapat diuji DAN bermanfaat bagi pengguna memaksa Anda untuk memikirkan hal-hal itu ... tanpa membocorkan detail implementasi ke antarmuka Anda.

— Berin Loritsch

@ user949300 Keluhan nomor satu tentang TDD mungkin adalah cara API dimodifikasi untuk "testability", dalam arti unit, sehingga hal-hal yang biasanya dienkapsulasi terbuka. Keluhan nomor dua mungkin bukan skala yang baik dari waktu ke waktu.

— Frank Hileman

@Kylee Tes otomatis lebih tua dari kata kunci "TDD". Perbedaannya adalah bahwa tes otomatis hanyalah apa yang Anda pikir harus diuji - tidak ada dogma, atau urutan khusus di mana Anda menulisnya. Juga tidak ada penekanan pada tes unit vs integrasi.

— Frank Hileman

0

A) Anda membaca kode dan meyakinkan diri sendiri bahwa itu benar tidak jauh dari membuktikan itu benar. Kalau tidak mengapa menulis tes sama sekali?

B) Ketika Anda mengubah kode Anda ingin menjalankan tes yang menunjukkan kode masih benar atau tidak.

— Josh
sumber

ini sepertinya hanya mengulangi poin yang dibuat (dan jauh lebih baik dijelaskan) dalam jawaban teratas yang telah diposting beberapa minggu sebelumnya

— nyamuk

@gnat Ini adalah tanggapan yang lebih ringkas untuk sesuatu yang tidak memerlukan novel yang ditulis tentangnya. Silakan coba berkontribusi sesuatu di sini.

— Josh

-1

Saya akan memperingatkan dengan mengatakan bahwa sekali Anda terbiasa menggunakan TDD secara efektif, itu akan menghemat waktu Anda di akhir permainan. Dibutuhkan latihan untuk mempelajari cara menggunakan TDD secara efektif, dan itu tidak membantu ketika Anda berada di bawah krisis waktu. Ketika belajar bagaimana memanfaatkannya dengan baik, saya sarankan memulai proyek pribadi di mana Anda memiliki lebih banyak waktu luang dan lebih sedikit tekanan jadwal.

Anda akan menemukan bahwa kemajuan awal Anda lebih lambat saat Anda bereksperimen lebih banyak dan membuat API Anda ditulis. Seiring waktu, kemajuan Anda akan lebih cepat karena tes baru Anda mulai berlalu tanpa mengubah kode, dan Anda memiliki basis yang sangat stabil untuk membangun. Pada akhir permainan, kode yang tidak dibangun menggunakan TDD mengharuskan Anda menghabiskan lebih banyak waktu dalam debugger saat Anda mencoba mencari tahu apa yang salah dari yang seharusnya diperlukan. Anda juga menghadapi risiko lebih besar untuk melanggar sesuatu yang dulu bekerja dengan perubahan baru. Menilai efektivitas TDD vs tidak menggunakannya dengan total waktu hingga selesai.

Konon, TDD bukan satu-satunya game di kota. Anda dapat menggunakan BDD yang menggunakan cara standar untuk mengekspresikan perilaku aplikasi tumpukan penuh, dan menilai kebenaran API dari sana.

Seluruh argumen Anda bergantung pada "membuktikan kebenaran kode", jadi Anda perlu sesuatu yang mendefinisikan kebenaran kode. Jika Anda tidak menggunakan alat otomatis untuk mendefinisikan apa artinya "benar", maka definisi tersebut sangat subyektif. Jika definisi Anda yang benar didasarkan pada konsensus rekan-rekan Anda, itu dapat berubah pada hari tertentu. Definisi Anda yang benar perlu konkret dan dapat diverifikasi, yang juga berarti harus dapat dievaluasi oleh suatu alat. Mengapa tidak menggunakannya?

Kemenangan # 1 dari menggunakan pengujian otomatis apa pun, adalah Anda dapat memverifikasi kode Anda tetap benar bahkan ketika tambalan OS diterapkan dengan cepat dan efisien. Jalankan suite Anda untuk memastikan semuanya lewat, lalu terapkan tambalan dan jalankan suite lagi. Lebih baik lagi, jadikan ini bagian dari infrastruktur build otomatis Anda. Sekarang Anda dapat memverifikasi kode Anda tetap benar setelah menggabungkan kode dari beberapa pengembang.

Pengalaman saya menggunakan TDD telah membawa saya ke kesimpulan berikut:

Ini bagus untuk kode baru, sulit untuk mengubah sistem lama
Anda masih harus tahu apa yang ingin Anda capai (mis. Punya rencana)
Lambat untuk memulai, tetapi menghemat waktu kemudian
Memaksa Anda berpikir tentang cara memvalidasi kebenaran dan debugging dari perspektif pengguna

Pengalaman saya menggunakan BDD telah membawa saya ke kesimpulan berikut:

Ini berfungsi untuk kode lama dan baru
Ini memvalidasi seluruh tumpukan, dan menentukan spesifikasi
Lebih lambat bangun dan berjalan (membantu memiliki seseorang yang mengetahui toolset)
Lebih sedikit perilaku yang perlu didefinisikan daripada tes unit

Definisi Benar: Kode Anda mematuhi persyaratan. Ini paling baik diverifikasi dengan BDD, yang menyediakan sarana untuk mengekspresikan persyaratan tersebut dengan cara yang dapat dibaca manusia dan memverifikasinya pada waktu berjalan.

Saya tidak berbicara tentang kebenaran dalam hal bukti matematis, yang tidak mungkin. Dan saya lelah dengan argumen itu.

— Berin Loritsch
sumber

Posting yang luar biasa yang membahas masalah yang membuat saya mempertimbangkan untuk memulai TDD: definisi "kebenaran kode" saat ini memang merupakan konsensus dari rekan-rekan. Kekhawatiran saya adalah bahwa ketika tim berubah di masa depan, metode ini akan berhenti bekerja. Tapi, bagaimana TDD akan menyelesaikan ini? Sementara tes lama dapat menyelamatkan anggota tim baru dari kerusakan fungsi lama dengan mudah, mereka mungkin masih menulis tes tidak lengkap untuk fitur masa depan, yang masih akan menyebabkan masalah. Pada akhirnya, kedua metode ini mengandalkan kepercayaan tim Anda. Saya belum pernah mendengar BDD sebelumnya, jadi saya akan memeriksanya juga. Terima kasih.

— Kylee

2

"Anda dapat memverifikasi kode Anda tetap benar" Tidak. Bahkan tidak dekat. Paling banyak Anda dapat mengklaim bahwa tes yang telah Anda jalankan masih lulus.

— Bent

@Kylee, alamat BDD yang memprihatinkan lebih baik. BDD meminta Anda menulis spesifikasi yang dapat diverifikasi. Spesifikasi tersebut ditulis dalam bahasa alami Anda dengan cara membuat kaitan dengan kode uji aktual yang memverifikasi spesifikasi tersebut. Itu menjembatani dua masalah, mengomunikasikan persyaratan aktual dan menegakkannya.

— Berin Loritsch

1

@ Bent, Tolong jangan berdebat tentang "kebenaran" dalam hal bukti matematika. Itu bukan topik pembicaraan atau apa yang ingin saya sampaikan. Namun, berdasarkan pengalaman orang-orang yang memposting komentar seperti Anda cenderung memiliki itu dalam pikiran. Anda benar-benar dapat memverifikasi bahwa kode memenuhi persyaratan. Itulah definisi kerja yang benar yang saya bicarakan.

— Berin Loritsch

Masalahnya adalah, Anda mengemudi ke definisi "benar", di mana persyaratannya adalah bahwa kode lulus tes yang telah Anda tetapkan. Set input lainnya adalah perilaku yang tidak terdefinisi, dan outputnya arbitrer. Ini tidak benar-benar cocok dengan apa yang dianggap sebagian besar pengguna sebagai persyaratan.

— Simon B