Apakah saya perlu menguji semuanya?

28

Saya akan memulai proyek nyata pertama saya di Ruby on Rails , dan saya memaksakan diri untuk menulis tes TDD . Saya tidak melihat keuntungan nyata dalam tes menulis, tetapi karena tampaknya sangat penting, saya akan mencoba.

Apakah perlu untuk menguji setiap bagian dari aplikasi saya, termasuk halaman statis?

testing tdd

— Matteo Pagliazzi
sumber

9

Ini benar-benar bukan ruby pada pertanyaan rel. ini lebih merupakan pertanyaan TDD.

— Jon Strayer

4

@ JonStrayer: Benarkah? Apakah Anda yakin jawabannya akan sama untuk RoR sebagai .NET? Saya akan menyarankan bahwa dengan desain RoR sengaja mengurangi biaya pengujian, sementara tidak memiliki jenis-keselamatan dalam bentuk kompiler secara besar-besaran meningkatkan manfaat pengujian.

— pdr

1

Untuk beberapa alasan, pertanyaan ini membuat saya ingin memposting makro gambar Kapten Nero berteriak "TEST EVERYTHING !!!"

— Mason Wheeler

3

Tidak melihat keuntungan nyata dalam menulis tes dan menuliskannya dari keyakinan buta tidak terdengar benar. Lanjutkan tanpa menulis tes, setelah beberapa saat Anda akan mengalami regresi yang tidak terduga dan tahu mengapa Anda menguji.

— ZJR

1

Tunggu hingga Anda memutuskan untuk menyusun ulang kode Anda. Setiap kali perubahan besar diperkenalkan, Anda perlu memverifikasi fungsionalitas. Tanpa tes Anda harus melalui aplikasi Anda dan menguji semua fungsi secara manual. Kenalkan pembaruan besar lainnya dan Anda harus melakukannya lagi. Tes unit hanyalah cara 'murah' untuk memastikan semuanya berjalan seperti yang diharapkan.

— Evan Plaice

47

TDD bukan tentang pengujian, ini tentang desain. Menulis tes memaksa Anda untuk berpikir tentang bagaimana kelas seharusnya bekerja dan antarmuka apa yang Anda butuhkan. Tes ini merupakan efek samping yang menyenangkan yang membuatnya lebih mudah untuk refactor nanti.

Jadi, dengan itu dalam pikiran, apa perilaku halaman statis dan apa antarmuka?

Tanggapan pertama saya adalah "tidak ada" dan "tidak ada".

— Jon Strayer
sumber

jadi tidak ada tes untuk halaman statis?

— Matteo Pagliazzi

TDD, pada tingkat tertentu, tentang desain. Tetapi Anda masih membutuhkan arsitektur. Tanpa arsitektur dalam pikiran, sulit untuk membayangkan bagaimana seseorang akan tumbuh secara organik dari sekelompok tes.

— Robert Harvey

@MatteoPagliazzi Tergantung pada tingkat pengujian (tes unit / tes integrasi / dll), mungkin satu atau dua, untuk mengonfirmasi halaman statis dapat diakses. Tapi itu level yang terlalu tinggi untuk unit test.

— Izkata

1

@ RobertTarvey Saya tidak mengatakan jangan menguji apa pun. Saya katakan jangan unit menguji halaman statis.

— Jon Strayer

@ JonStrayer: TDD cenderung menahan TDD sebagai beberapa ramuan ajaib untuk desain; Saya minta maaf jika itu bukan yang Anda maksud. :)

— Robert Harvey

32

Itu selalu merupakan analisis biaya-manfaat. Berapa biaya fitur yang dihilangkan untuk Anda? Jika biayanya tinggi, maka uji dengan baik dan menyeluruh. Jika biayanya rendah, uji ringan atau tidak sama sekali.

Ada juga biaya waktu ke pasar untuk dipertimbangkan. Mungkin lebih baik bagi Anda untuk memberikan sebagian besar fitur yang berfungsi daripada terlambat memberikan fitur yang sepenuhnya berfungsi.

Hampir mustahil untuk menjawab pertanyaan-pertanyaan ini di IMO umum.

Saya pikir ini lebih penting untuk menjaga kemampuan untuk menguji dalam hal beberapa fitur ternyata lebih penting daripada yang Anda sadari.

— Doug T.
sumber

Juga, saya akan berasumsi bug di halaman statis akan JAUH lebih mudah untuk diperbaiki daripada kesalahan logika, kesalahan desain, dan jenis hal yang biasanya digunakan untuk mencegah TDD. Baik menemukan dan memperbaiki kesalahan halaman statis cenderung cukup mudah, dan kesan saya bahwa TDD digunakan untuk mempersingkat kedua proses ketika mereka membutuhkan waktu lebih lama dari yang diinginkan. : D

— Gordon Gustafson

Saya tidak akan menganggap itu. Jika Anda pernah berurusan dengan perilaku versi peramban yang tidak jelas atau masalah memori javascript yang aneh, kemungkinan besar Anda akan cukup berolahraga. Lebih sering sebagai bahasa back-end bisa menjadi sedikit lebih dapat diandalkan dan standar. terkadang. Mungkin Anda berbicara tentang statis seperti pada html dan tanpa javascript.

— Michael Durrant

8

Saya akan mengatakan "ya". Jika Anda memiliki tes yang mencakup bahkan fitur dan kode paling sederhana, maka Anda dapat memiliki keyakinan bahwa menambahkan kode baru tidak menyebabkan kode di tempat berhenti bekerja. Demikian pula, melakukan tes untuk setiap bug yang Anda temui membuat regresi tidak masuk kembali.

— Bruce Ediger
sumber

"maka Anda dapat memiliki keyakinan bahwa menambahkan kode baru tidak menyebabkan kode di tempat berhenti bekerja" dengan cara itu saya tidak boleh menyentuh sepotong kode yang telah saya tulis sebelumnya dan hanya menambahkan metode baru?

— Matteo Pagliazzi

Ya tidak. Tetapi dependensi yang tidak terduga dan tidak terencana antara kode yang saat ini "berfungsi" dapat menyebabkan masalah jika Anda menambahkan kode baru yang mengubah dependensi tersebut. Juga, jika Anda mendapatkan tes yang salah, yang menurut saya cukup umum, Anda harus memodifikasi tes itu sendiri, dan kemudian, mungkin, memodifikasi kode yang timbul dari tes itu.

— Bruce Ediger

@Andy Itu omong kosong. Menguji setter dan getter properti adalah sepele dan VITAL. Jika mereka tidak berhasil, umumnya seluruh kelas berantakan. Misalnya, dalam aplikasi multithreaded, jika set tidak mencegah secara bersamaan, maka Anda akan mendapatkan masalah data yang rusak yang bisa memakan waktu berjam-jam untuk sampai ke bawah, karena sumber data akan benar, tetapi hasil yang didapat tidak akan Atau jika set Anda gagal juga memperbarui waktu pembaruan, maka data Anda menjadi tidak mungkin untuk disinkronkan Anda mendapatkan ide. Jika setter dan getter benar-benar sepele, Anda bisa menjadikannya milik publik

— deworde

@deworde Saya khawatir membuat anggota thread aman tidak terlalu umum. Ini lebih biasa untuk mengontrol akses ke tipe aman non-thead daripada mencoba untuk membuat mereka aman. Bagaimanapun, apa yang harus diuji adalah hal yang menguntungkan biaya, sebagaimana dinyatakan oleh jawaban lain. Anda dapat menghabiskan waktu menulis tes untuk getter atau setter atau Anda dapat menguji perilaku aktual sistem Anda seharusnya merangkum.

— Andy

3

Ya, Anda harus menguji semuanya ...

Anda tidak perlu dapat menulis tes otomatis untuk semuanya. Untuk halaman statis Anda, lihat menggunakan Selenium http://seleniumhq.org/ untuk memastikan semuanya benar.

Dari pengalaman saya, beberapa hal ujung depan hampir tidak mungkin untuk menulis kasus uji untuk tetapi itu sebabnya Anda benar-benar ingin menguji menggunakan bola mata Mark 1.

— Schleis
sumber

Saya tidak setuju. Jika Anda tidak dapat mewujudkannya baik melalui tiruan atau mengirimkan data, lalu mengapa ada dalam kode Anda. Getters dan setter yang tidak memerlukan pengujian mereka sendiri akan diuji melalui unit test lain dari sistem untuk memverifikasi fungsionalitas yang diharapkan.

— Schleis

Tentu, setter / getter diuji secara tidak langsung dengan tes lain tetapi ketika seseorang mengatakan "uji segalanya" saya berasumsi mereka membuat tes khusus untuk hal-hal semacam itu. Saya selalu memberi tahu orang-orang "menguji hal-hal penting." Hal-hal seperti setter dan getter tidak cocok dengan definisi itu untuk saya.

— Andy

2

Pengujian sama pentingnya dengan pengkodean. Anda harus mendengar pepatah "Jika ada sesuatu yang salah, itu akan". INMO, Dari banyak teknik rekayasa perangkat lunak yang digunakan untuk meningkatkan kualitas, Pengujian adalah yang paling berharga dalam membantu Anda menemukan masalah sejak dini.

Meskipun pengujian semuanya tidak mungkin (khususnya dengan tim kecil dan sistem besar), itu tidak berarti Anda melewatkan pengujian sama sekali. Apakah pengujian sepadan? Lihat bagian "Menemukan kesalahan lebih awal" di See Wiki-SoftwareTesting .

— Tidak ada kesempatan
sumber

2

Tes TDD juga bisa menjadi spesifikasi hidup jika ditulis seperti itu. Nama-nama metode pengujian harus masuk akal bagi pengguna bisnis.

— Chriseyre2000
sumber

2

Seperti yang disebutkan orang lain, dalam pengujian Ruby on Rails jauh lebih penting daripada di (sebagian besar) bahasa lain. Ini karena kurangnya kompiler.

Bahasa seperti Delphi , C ++, VB.NET , dll ... adalah bahasa yang dikompilasi, dan kompiler Anda akan mengambil banyak mistkes seperti kesalahan ketik dalam panggilan ke suatu metode. Di Ruby on Rails Anda hanya akan tahu apakah ada kesalahan ketik atau kesalahan dalam kode Anda jika baris kode tertentu dijalankan atau Anda menggunakan IDE yang menampilkan peringatan visual.

Karena SETIAP baris kode penting (jika tidak, tidak akan ada di sana) Anda harus menguji setiap metode yang Anda tulis. Ini jauh lebih sederhana daripada kedengarannya jika Anda mengikuti beberapa alat TBDD dasar.

Saya menemukan bahwa Ryan Bates' Rails Cast pada Bagaimana saya tes sangat berharga bagi saya dan benar-benar menyoroti kesederhanaan TBDD jika dilakukan dengan benar.

— jamesc
sumber

1

Jika Anda benar-benar menggunakan metodologi TDD maka Anda tidak menulis kode tanpa terlebih dahulu memiliki unit test yang Anda coba lewati.

— terima kasih
sumber

2

ya ... tetapi misalnya di halaman statis apa yang harus saya uji? keberadaannya? bahwa konten dan tautan ada? mungkin saya salah tetapi sepertinya buang-buang waktu ...

— Matteo Pagliazzi

1

Saya cenderung berpikir bahwa metodologi TDD diterapkan pada logika Anda. Apakah halaman statis Anda adalah file html? Tampilan MVC yang tidak pernah berubah? Jika yang terakhir saya kira Anda bisa menguji bahwa controller Anda mengembalikan tampilan yang tepat. Saya pikir hal yang lebih penting adalah untuk mengingat bahwa TDD seharusnya dapat membantu Anda mengembangkan terhadap spesifikasi Anda bukan hanya "tes" ...

— wessiyad

Saya berasumsi Anda hanya melayani halaman statis dengan komponen kerangka kerja. Jika tidak ada metode Anda menyentuh halaman itu, sebenarnya tidak ada yang bisa diuji. Anda juga tidak perlu menguji Rails. Saya pikir seseorang memiliki itu.

— Erik Reppen

0

Saya akan mengatakan untuk tidak memulai dengan TDD. Buat keputusan berdasarkan informasi saat Anda menghabiskan lebih banyak waktu mempelajari strategi arsitektur secara umum. TDD tidak akan membiarkan Anda melewatkan pekerjaan rumah itu meskipun Anda mungkin mulai percaya itu.

Inilah masalah saya dengan itu. Ketika Anda mengatakan sepertinya banyak waktu terbuang untuk hal-hal yang tidak akan pernah melanggar TDDers mengatakan Anda akan menghargainya ketika satu hal yang tidak Anda antisipasi dalam rantai besar dependensi menjadi rusak. Ketika Anda menunjukkan bahwa tidak mungkin untuk memprediksi hal-hal seperti itu sebelum Anda menulis aplikasi Anda, yang merupakan ... mengapa kami menguji, mereka memberi tahu Anda itu benar-benar lebih banyak tentang desain dan tidak menguji meskipun pengujian itu berguna.

Tetapi bukankah rantai raksasa dari ketergantungan terkait yang tidak dapat diprediksi merupakan produk dari desain jelek?

Jadi yang mana?

Inilah sebuah pemikiran. Mari kita tidak memiliki rantai besar ketergantungan yang rumit di tempat pertama dengan mempertimbangkan dua prinsip desain berorientasi objek berikut dari Pola Desain:

"Program ke antarmuka, bukan implementasi"

Dengan kata lain, objek Anda seharusnya tidak peduli siapa yang melakukan pemanggilan atau bagaimana mereka dibuat. Hanya arg yang tepat dimasukkan dan metode yang mereka panggil dari objek lain yang diarahkan untuk bekerja seperti yang diharapkan. Rantai ketergantungan Anda dalam kebanyakan kasus harus berada pada satu titik penghubung, pemanggilan metode pada bagian pemanggil dan tempat di mana args dimasukkan ke dalam metode Anda. Di situlah Anda login dan memvalidasi dan mengirim pesan yang berguna untuk debug ketika hal-hal buruk.

Dan:

"Komposisi objek yang disukai daripada warisan kelas"

Siapa boneka itu? Orang yang melakukan sesuatu pada suatu kelas dalam skema pewarisan cascading yang berbelit-belit yang melibatkan seperti 30 kelas yang mengakibatkan kerusakan case fringe, atau dev yang muncul dengan arsitektur itu sejak awal? TDD mungkin membantu Anda menyelesaikan masalah di dalam menara miring kelas Pisa lebih cepat daripada yang bisa Anda dapatkan tanpa itu, tetapi apakah itu membuatnya lebih tidak menyakitkan untuk mencoba memodifikasi salah satu titik akhir dari bencana kode itu di waktu berikutnya?

Dan di situlah saya sampai pada hal yang mengganggu saya. Apakah TDD benar-benar membantu desain atau apakah itu memungkinkan arsitektur yang buruk? Bagi saya sepertinya memiliki potensi untuk menjadi strategi yang memuaskan diri sendiri. Semakin banyak tim Anda tidak harus memiliki tanggung jawab untuk arsitektur yang buruk, komponen-komponen pengujian granular yang lebih bermanfaat tampaknya menjadi, tetapi akhirnya aplikasi Anda menjadi PITA semakin besar untuk bekerja dengan (dengan asumsi mereka tidak pernah terlalu memikirkan arsitektur di pertama tempat). Dan kegagalan untuk mengakui konsekuensi dari itu adalah turun tangan, selalu kesalahan paling mahal yang dapat Anda buat ketika bekerja pada aplikasi yang dimaksudkan untuk ditingkatkan dan dimodifikasi dari waktu ke waktu.

— Erik Reppen
sumber

-1

Untuk menjawab pertanyaan, pikirkan tentang "apa yang salah di sini". Khususnya, jika Anda mengubah "kode" (markup / apa pun), bagaimana Anda akan memiliki keyakinan bahwa Anda belum merusak halaman. Nah, untuk halaman statis:

mungkin tidak membuat
mungkin membuat salah
JS mungkin tidak dimuat
jalur untuk gambar mungkin tidak berfungsi
tautannya mungkin rusak

Secara pribadi, saya akan merekomendasikan:

tulis tes selenium [1] yang memeriksa satu string yang Anda harapkan pada halaman (dekat bagian bawah jika memungkinkan). Ini memvalidasi yang ditampilkannya.
periksa tidak ada kesalahan JS (saya pikir selenium memungkinkan ini)
jalankan halaman statis melalui validator html, dan jika mungkin, pemeriksa tautan.
Saya belum menemukan alat yang saya suka untuk memvalidasi JS, tetapi Anda mungkin menemukan kesuksesan dengan jslint atau jshint.

Yang perlu dilakukan di sini adalah Anda menginginkan sesuatu yang dapat diulang, mudah digunakan, dan akan berjalan secara otomatis di pelari pengujian Anda.

— Paul Biggar
sumber

-1

Untuk menambahkan semua jawaban yang sudah sangat bagus, inilah pemikiran saya tentang apa yang harus diuji, dan apa yang tidak untuk diuji:

Lakukan tes:

logika bisnis
logika aplikasi
fungsionalitas
tingkah laku,
jadi, semuanya, sungguh, kecuali :

Jangan tes:

konstanta
presentasi

Jadi tidak ada gunanya melakukan tes yang mengatakan:

assert wibble = 3

dan beberapa kode yang mengatakan

wibble = 3

Dan juga tidak ada gunanya menguji hal-hal presentasi, seperti apakah ikon dalam perywinkle blue, font apa yang Anda gunakan untuk pos, dan seterusnya ...

Jadi, Anda bertanya, "haruskah saya menguji halaman statis", dan jawabannya adalah: Anda mengujinya sejauh itu merupakan bagian dari fungsionalitas, logika bisnis, atau perilaku situs Anda.

Jadi, di aplikasi kami, kami memiliki tes yang memeriksa bahwa syarat & ketentuan tersedia dari setiap bagian situs - untuk pengguna anonim, untuk pengguna yang masuk, dari dasbor, di dalam layar aplikasi dll. Itu hanya memeriksa bahwa ada sebuah tautan yang disebut "syarat dan ketentuan" pada setiap halaman, bahwa tautan itu berfungsi, dan kemudian tes tersebut mengatakan bahwa ketika itu tiba di halaman, itu "terlihat seperti" Ts & Cs - hanya cukup untuk meyakinkan diri sendiri itu adalah halaman yang tepat, tanpa "menguji konstanta", atau "menguji presentasi" ... sehingga Anda dapat memeriksa apakah teksnya benar, misalnya, tanpa memeriksa ukuran font atau tata letak teks tertentu ...

— hwjp
sumber