Jadi kami menghabiskan banyak waktu
dalam beberapa terakhir dari kuliah
berbicara tentang berbagai jenis pengujian
tentang pengujian versus integrasi pengujian unit
Kami berbicara tentang bagaimana Anda menggunakan RSpec
untuk benar-benar mengisolasi bagian dari kode Anda ingin menguji
kau juga, Anda tahu, karena PR 3,
dan hal-hal lain, kita telah melakukan BDD,
di mana kita telah menggunakan mentimun untuk mengubah cerita pengguna
ke dalam, pada dasarnya, integrasi dan penerimaan tes
Jadi Anda telah melihat pengujian dalam beberapa tingkat yang berbeda
dan tujuan di sini adalah semacam melakukan beberapa komentar
kau tahu, mari kita kembali sedikit
melihat gambaran besar dan mengikat hal-hal bersama-sama
Jadi ini semacam meliputi bahan
yang mencakup tiga atau empat bagian dalam buku
dan saya ingin hanya memukul poin yang tinggi di kuliah
Jadi pertanyaan yang muncul
Saya yakin itu telah datang untuk kalian semua
seperti yang Anda telah melakukan pekerjaan rumah
adalah: "pengujian berapa banyak yang cukup?"
Dan, sayangnya, untuk waktu yang lama
jenis jika Anda bertanya pertanyaan ini dalam industri
Jawabannya adalah pada dasarnya
"Yah, kita memiliki tenggat waktu pengiriman,
Jadi namun banyak pengujian dapat kita lakukan
sebelum tenggat waktu itu, itu berapa banyak."
Itulah apa yang Anda punya waktu untuk.
Jadi, Anda tahu, itu sedikit flip
jelas tidak sangat baik
Sehingga Anda dapat melakukan sedikit lebih baik, kan?
Ada sudah beberapa langkah-langkah yang statis
seperti berapa banyak baris kode aplikasi Anda memiliki
dan berapa banyak baris tes Anda punya?
Dan ini bukan tidak biasa dalam industri
dalam sepotong diuji dengan baik perangkat lunak
untuk jumlah baris tes
untuk jauh melampaui jumlah baris kode
Jadi, integer kelipatan tidak biasa
Dan saya pikir bahkan untuk semacam itu, Anda tahu,
penelitian kode atau classwork
rasio, kau tahu, mungkin 1.5 tidak masuk akal
Jadi satu setengah kali jumlah tes kode
karena Anda memiliki kode aplikasi
Dan dalam banyak sistem produksi
di mana mereka benar-benar peduli tentang pengujian
Hal ini lebih tinggi dari itu
Jadi mungkin pertanyaan yang lebih baik untuk bertanya:
Alih-alih mengatakan "pengujian berapa banyak yang cukup?"
adalah dengan bertanya "bagaimana baik adalah pengujian yang saya lakukan sekarang?
Bagaimana menyeluruh itu?"
Kemudian di semester ini
Profesor Sen akan berbicara tentang
sedikit tentang metode formal
dan semacam Apakah pada batas-batas pengujian dan debugging
Tetapi beberapa hal-hal yang kita dapat berbicara tentang
berdasarkan apa yang Anda sudah tahu
adalah beberapa konsep dasar tentang cakupan uji
Dan meskipun aku akan mengatakan
kau tahu, kita sudah mengatakan sepanjang
metode formal, mereka tidak benar-benar bekerja pada sistem yang besar
Saya pikir pernyataan itu, dalam pendapat pribadi saya
benar benar-benar jauh lebih daripada dulu
Saya pikir ada sejumlah tempat tertentu
terutama dalam pengujian dan debugging
di mana metode formal benar-benar membuat kemajuan cepat
dan Koushik Sen adalah salah satu pemimpin dalam yang
Sehingga Anda akan memiliki kesempatan untuk mendengar lebih banyak tentang hal ini nanti
tapi untuk saat ini saya pikir, jenis roti dan mentega
adalah Mari kita bicara tentang cakupan pengukuran
karena ini adalah di mana karet meets the road
dalam hal bagaimana Anda akan dievaluasi
Jika Anda melakukan hal ini untuk real
Jadi apa adalah beberapa dasar-dasar?
Di sini adalah benar-benar sederhana dapat Anda gunakan
untuk berbicara tentang cara yang berbeda untuk mengukur
Bagaimana pengujian kami mencakup kode ini
Dan ada beberapa tingkatan yang berbeda
dengan terminologi yang berbeda
Hal ini tidak benar-benar universal di seluruh semua rumah perangkat lunak
Tapi umum satu set terminologi
buku mengekspos
adalah kita bisa bicara tentang S0
di mana kita akan hanya berarti Anda telah dipanggil setiap metode sekali
Sehingga Anda tahu, jika Anda memanggil foo, dan Anda memanggil bar, Anda sudah selesai
Itulah S0 cakupan: tidak sangat menyeluruh
Sedikit lebih ketat, S1, adalah
Anda dapat mengatakan, kita menyebut setiap metode
dari setiap tempat itu bisa disebut
Jadi apa artinya itu?
Itu berarti, misalnya
Ianya tidak cukup untuk memanggil bar
Anda harus memastikan bahwa Anda harus menyebutnya
setidaknya sekali dari di sini
serta menyebutnya sekali
dari setiap fungsi eksterior yang mungkin menyebutnya
C0 yang adalah apa yang mengukur SimpleCov
(mereka yang sudah SimpleCov dan berjalan)
pada dasarnya mengatakan bahwa Anda telah dilaksanakan setiap pernyataan
Anda telah menyentuh setiap pernyataan dalam kode Anda sekali
Tapi peringatan ada adalah bahwa
conditional benar-benar hanya dihitung sebagai satu pernyataan
Jadi, jika Anda, tidak peduli yang cabang ini "jika" Anda mengambil
selama Anda menyentuh salah satu cabang lainnya
Anda telah dieksekusi "jika ' pernyataan
Jadi bahkan C0 adalah masih, Anda tahu, liputan semacam dangkal
Tapi, seperti yang kita akan lihat
cara bahwa Anda akan ingin untuk membaca informasi ini adalah:
Jika Anda mendapatkan * buruk * cakupan setinggi C0
maka Anda memiliki cakupan yang benar-benar benar-benar buruk
Jadi jika Anda tidak baik membuat
tingkat ini sederhana liputan dangkal
maka pengujian Anda mungkin kurang
C1 adalah langkah berikutnya dari itu
Kita bisa mengatakan:
Yah, kita harus mengambil setiap cabang di kedua arah
Jadi, ketika kita melakukan pernyataan "jika" ini
kita harus memastikan bahwa
kita lakukan "Jika x" bagian sekali
dan "jika tidak x" bagian setidaknya sekali untuk memenuhi C1
Anda dapat menambah bahwa dengan keputusan cakupan
berkata: Yah, kalau kita gonna…
Jika kita memiliki "jika" statments di mana kondisi
terdiri dari beberapa istilah
kita harus memastikan bahwa setiap subexpression
telah dievaluasi kedua arah
Dengan kata lain, yang berarti bahwa
Jika kita akan gagal pernyataan "jika" ini
kita harus pastikan untuk gagal itu setidaknya sekali
karena y palsu dalam sekurang-kurangnya sekali karena z palsu
Dengan kata lain, setiap subexpression yang bisa
independen mengubah hasil dari kondisi
harus dilaksanakan di kedua arah
Dan kemudian,
jenis, yang itu, kau tahu, banyak orang bercita-cita untuk
Namun ada ketidaksepakatan tentang berapa banyak lebih berharga itu
Anda mengambil setiap jalan melalui kode
Jelas, ini agak sulit karena
itu cenderung menjadi eksponensial dalam beberapa kondisi
Dan secara umum sulit
untuk mengevaluasi jika Anda telah meluangkan setiap jalan melalui kode
Ada teknik formal yang dapat Anda gunakan
untuk memberitahu Anda di mana lubang
tapi intinya adalah bahwa
di rumah-rumah perangkat lunak komersial
Aku akan berkata, tidak ada konsensus lengkap
pada berapa banyak lagi berharga C2 adalah
dibandingkan dengan C0 atau C1
Jadi, saya kira, dengan tujuan untuk kelas kami
Anda mendapatkan terpapar ide
Bagaimana Anda menggunakan cakupan informasi
SimpleCov mengambil keuntungan dari beberapa fitur Ruby built-in
untuk memberikan C0 cakupan
[Itu] tidak benar-benar baik laporan
Kita bisa melihat itu semacam
pada tingkat setiap baris dalam file Anda
Anda dapat melihat apakah Anda cakupan
dan saya rasa itulah jenis, Anda tahu
awal yang baik untuk di mana kita berada
Jadi, setelah melihat semacam rasa yang berbeda dari tes
Melangkah mundur dan melihat kembali pada gambaran besar
apa yang berbeda tes
yang kita lihat secara konkret?
dan apa yang dilema
antara menggunakan orang-orang macam tes?
Jadi kita telah melihat pada tingkat kelas individu atau metode
Kami menggunakan RSpec, dengan luas penggunaan mengejek dan stubbing
Jadi, misalnya ketika kita melakukan pengujian metode dalam model
yang akan menjadi contoh unit testing
Kami juga melakukan sesuatu yang sangat mirip dengan
fungsional atau modul pengujian
di mana ada lebih dari satu modul berpartisipasi
Jadi, misalnya ketika kami melakukan controller spesifikasi
kita melihat bahwa-kami mensimulasikan tindakan posting
tapi ingat bahwa tindakan posting
harus pergi melalui subsistem routing
sebelum sampai ke controller
Setelah controller selesai ia akan mencoba untuk membuat tampilan
Jadi bahkan ada potongan lain
yang berkolaborasi dengan controller
yang harus bekerja dalam rangka untuk controller spesifikasi untuk lulus
Jadi itu adalah suatu tempat Peralihan:
di mana kami melakukan lebih dari satu metode
menyentuh lebih dari satu kelas
tapi kami masih berkonsentrasi perhatian [kita]
di sepotong cukup sempit sistem pada satu waktu
dan kami masih menggunakan mengejek dan stubbing luas
untuk mengisolasi semacam itu perilaku yang kita ingin menguji
Dan kemudian pada tingkat mentimun skenario
ini lebih seperti integrasi atau sistem tes
Mereka melaksanakan lengkap jalan di seluruh aplikasi
Mereka mungkin menyentuh banyak modul yang berbeda
Mereka memanfaatkan minimal mengolok-olok dan Rintisan bertopik
karena bagian dari tujuan integrasi menguji
Itulah untuk menguji interaksi antara lembar
Jadi Anda tidak ingin tulisan rintisan atau mengontrol interaksi mereka
Anda benar-benar ingin membiarkan sistem yang melakukan
akan benar-benar apa
Jika ini adalah skenario yang terjadi dalam produksi
Jadi bagaimana kita membandingkan berbagai jenis tes?
Ada beberapa sumbu yang berbeda kita dapat melihat
Salah satunya adalah berapa lama mereka ambil untuk menjalankan
Sekarang, RSpec dan ketimun
memiliki, jenis, awal tinggi kali dan hal-hal seperti itu
Tapi, seperti yang akan Anda lihat
Ketika Anda mulai menambahkan lebih banyak dan lebih RSpec tes
dan menggunakan autotest untuk menjalankan mereka di latar belakang
pada umumnya, sekali RSpec jenis terangsang pad peluncuran
membentang spesifikasi yang benar-benar cepat
sedangkan menjalankan mentimun fitur hanya memakan waktu yang lama
karena pada dasarnya kebakaran Anda seluruh aplikasi
Dan kemudian di semester ini
kita akan melihat cara untuk membuat mentimun lebih lambat-
yang akan memilikinya api seluruh browser
pada dasarnya bertindak seperti boneka, remote-mengendalikan Firefox
Jadi Anda dapat menguji kode Javascript
Kami akan melakukan bahwa ketika kita benar-benar —
Saya pikir kita akan mampu bekerja dengan teman-teman kita di SourceLabs
sehingga Anda dapat melakukannya di awan-yang akan menarik
Jadi, "lari cepat" versus "berjalan lambat"
Resolusi:
Jika kesalahan terjadi di unit Anda tes
Hal ini biasanya cukup mudah
untuk mengetahui dan melacak apa sumber kesalahan itu adalah
karena tes begitu terisolir
Anda telah stubbed keluar segala sesuatu yang tidak peduli
dan Anda berfokus pada hanya perilaku bunga
Jadi, jika Anda telah melakukan pekerjaan yang baik melakukan hal itu
ketika sesuatu yang tidak beres di salah satu tes Anda
tidak ada banyak tempat
itu sesuatu yang bisa pergi salah
Sebaliknya, jika Anda menjalankan skenario mentimun
yang punya, Anda tahu, 10 langkah
dan setiap langkah menyentuh
sejumlah besar potongan-potongan dari app
bisa memakan waktu lama
benar-benar mendapatkan ke bawah bug
Jadi itu adalah jenis tradeoff
antara seberapa baik dapat Anda pelokalan kesalahan
Cakupan:
Dimungkinkan jika Anda menulis paket yang baik
unit dan tes fungsional
Anda bisa mendapatkan benar-benar tinggi cakupan
Anda dapat menjalankan laporan SimpleCov
dan Anda dapat benar-benar mengidentifikasi baris tertentu dalam file Anda
yang tidak dilaksanakan oleh tes
dan kemudian Anda dapat pergi kanan di tes yang menutupi mereka
Jadi, mencari tahu bagaimana untuk meningkatkan cakupan Anda
misalnya di tingkat C0
adalah sesuatu yang jauh lebih mudah dilakukan dengan unit test
Padahal, dengan tes mentimun —
dengan skenario mentimun —
Anda * adalah * menyentuh banyak bagian dari kode
tapi Anda melakukannya sangat jarang
Jadi, jika tujuan Anda adalah untuk mendapatkan liputan Anda
penggunaan alat-alat yang pada saat itu berada di tingkat unit
sehingga Anda dapat berfokus pada pemahaman
bagian apa atau kode saya adalah undertested
dan kemudian Anda dapat menulis tes yang sangat bertarget
hanya untuk fokus pada mereka
Dan, semacam itu, kau tahu, menempatkan potongan-potongan bersama-sama
unit test
karena dari isolasi mereka dan resolusi mereka baik-baik saja
cenderung menggunakan banyak mengolok-olok
untuk mengisolasi perilaku Anda tidak peduli
Tapi itu berarti bahwa, menurut definisi
Anda tidak pengujian antarmuka
dan itu adalah semacam "menerima kebijaksanaan" dalam perangkat lunak
bahwa banyak menarik bug
terjadi pada antarmuka antara lembar
dan tidak semacam dalam kelas atau dalam metode —
mereka adalah semacam bug yang mudah untuk melacak
Dan pada ekstrim yang lain
semakin Anda mendapatkan menuju pengujian integrasi ekstrim
Kau seharusnya kurang dan kurang mengandalkan mengolok-olok
untuk alasan yang tepat
Sekarang kita lihat, jika Anda menguji sesuatu seperti
mengatakan, dalam SOA
di mana Anda harus berinteraksi dengan situs remote
Anda masih berakhir
harus melakukan cukup banyak mengejek dan stubbing
sehingga Anda tidak bergantung pada Internet
dalam rangka untuk tes Anda untuk lulus
tetapi, secara umum
Anda mencoba untuk menghapus sebanyak mengolok-olok yang dapat Anda
dan membiarkan sistem menjalankan cara yang itu akan mencalonkan diri dalam kehidupan nyata
Jadi, kabar baiknya adalah Anda * adalah * pengujian antarmuka
* tapi * ketika sesuatu berjalan salah dalam salah satu antarmuka
karena resolusi Anda tidak sebagus
mungkin butuh waktu lebih lama untuk mencari tahu apa itu
So, what's semacam sedikit tinggi urutan dari tradeoff ini
Anda benar-benar tidak ingin bergantung
terlalu berat pada jenis satu tes
Mereka melayani tujuan yang berbeda dan, tergantung pada
Apakah Anda mencoba untuk latihan Anda antarmuka yang lebih
atau Anda mencoba untuk meningkatkan cakupan denda-butiran
yang mempengaruhi bagaimana Anda mengembangkan test suite
dan Anda akan berkembang bersama dengan perangkat lunak Anda
Jadi, kami telah menggunakan serangkaian terminologi dalam pengujian
Ini adalah istilah yang, oleh dan besar
ini paling sering digunakan dalam komunitas Rails
tetapi ada beberapa variasi
[dan] beberapa istilah lain bahwa Anda mungkin mendengar
Jika Anda pergi mendapatkan pekerjaan di suatu tempat
dan Anda mendengar tentang mutasi pengujian
yang belum kita lakukan
Ini adalah ide yang menarik, saya pikir, diciptakan oleh
Ammann dan Offutt, yang memiliki, semacam
buku definitif pengujian perangkat lunak
Idenya adalah:
Kira saya memperkenalkan bug yang disengaja ke kode saya
Apakah yang memaksa beberapa tes gagal?
Karena, jika aku berubah, Anda tahu, "Jika x" untuk "jika tidak x"
dan tidak ada tes gagal, maka baik aku kehilangan beberapa liputan
atau saya app sangat aneh dan entah bagaimana nondeterministic
Fuzz pengujian, yang Koushik Sen mungkin berbicara lebih banyak tentang
pada dasarnya, ini adalah "10.000 monyet di mesin tik
melemparkan masukan acak pada kode Anda"
Apa yang menarik tentang hal itu adalah bahwa
Kami telah melakukan tes
pada dasarnya yang dibuat untuk menguji app
Cara dirancang
dan ini, Anda tahu, fuzz pengujian
tentang pengujian app dalam cara itu * tidak * dimaksudkan untuk digunakan
Jadi, apa yang terjadi jika Anda melempar pengiriman form besar
Apa yang terjadi jika Anda meletakkan kontrol karakter dalam bentuk Anda?
Apa yang terjadi jika Anda mengirimkan hal yang sama berulang-ulang?
Dan, Koushik memiliki statistik yang
Microsoft menemukan hingga 20% bug mereka
menggunakan beberapa variasi fuzz pengujian
dan sekitar 25 %
Program baris perintah Unix yang umum
dapat dibuat untuk crash
[ketika] menempatkan melalui agresif fuzz pengujian
Penggunaan mendefinisikan cakupan adalah sesuatu yang belum kita lakukan
tapi itu adalah konsep menarik lain
Idenya adalah bahwa pada setiap titik dalam program saya
ada tempat di mana aku mendefinisikan —
atau saya menetapkan nilai ke beberapa variabel-
dan kemudian ada tempat Hilir
di mana mungkin aku akan mengkonsumsi nilai-
seseorang akan menggunakan nilai tersebut
Memiliki aku menutupi setiap pasangan?
Dengan kata lain, punya tes di mana setiap pasangan
mendefinisikan variabel dan menggunakannya di suatu tempat
dieksekusi di beberapa bagian dari test suites
Kadang-kadang disebut DU-cakupan
Dan ketentuan lain yang saya pikir tidak secara luas digunakan lagi
BlackBox versus whitebox, atau blackbox versus glassbox
Secara kasar, tes blackbox adalah salah satu yang ditulis dari
sudut pandang spesifikasi eksternal yang
[Misalnya:] "Ini adalah tabel hash
Ketika saya meletakkan di kunci saya harus mendapatkan kembali nilai
Jika saya menghapus kunci nilai boleh ada"
Itu adalah tes blackbox karena ia tidak mengatakan
apa-apa tentang bagaimana tabel hash diimplementasikan
dan tidak mencoba untuk stres pelaksanaan
Tes whitebox sesuai mungkin:
"Aku tahu sesuatu tentang fungsi hash
dan aku akan untuk sengaja menciptakan
kunci Hash di saya uji kasus
yang menyebabkan banyak hash tabrakan
untuk memastikan bahwa aku pengujian bagian fungsi"
Sekarang, C0 tes cakupan alat, seperti SimpleCov
akan mengungkapkan bahwa jika semua yang Anda miliki adalah blackbox tes
Anda mungkin menemukan bahwa
kode cakupan tabrakan tidak dipukul sangat sering
Dan yang mungkin Anda tip off mengatakan:
"Ok, jika benar-benar ingin untuk memperkuat bahwa-
untuk satu, jika saya ingin meningkatkan cakupan untuk tes
Sekarang aku harus menulis whitebox atau tes glassbox
Aku harus melihat ke dalam, melihat apa pelaksanaan
dan menemukan cara-cara khusus
untuk mencoba memecahkan pelaksanaan dalam cara-cara jahat"
Jadi, saya pikir, pengujian semacam cara hidup, benar?
Kita sudah jauh dari tahap
"Kita akan membangun semuanya dan kemudian kami akan menguji it"
dan kita sudah ke tahap
"Kami sedang menguji sebagai kita pergi"
Pengujian benar-benar lebih mirip sebuah alat pengembangan
dan seperti begitu banyak alat-alat pengembangan
efektivitas itu tergantung
pada apakah Anda menggunakannya dalam cara yang gurih
Jadi, Anda bisa mengatakan: "Yah, mari kita lihat-saya menendang ban
Kau tahu, aku bersemangat browser, saya mencoba beberapa hal
(tepuk tangan tangan) Tampak seperti itu bekerja! Menyebarkan!"
Itulah jelas cavalier lebih sedikit daripada yang Anda ingin menjadi
Dan, omong-omong, salah satu hal yang kami menemukan
dengan kursus online ini hanya memulai
Ketika 60.000 orang terdaftar dalam kursus
dan 0,1% dari orang-orang memiliki masalah
Anda akan mendapatkan email 60
Wajar adalah: bila situs Anda digunakan oleh banyak orang
beberapa bug bodoh bahwa Anda tidak menemukan
tapi yang bisa ditemukan dengan menguji
bisa sangat cepat menghasilkan * banyak * sakit
Di sisi lain, Anda tidak ingin dogmatis dan mengatakan
"Eh, sampai kami punya 100% cakupan dan menguji setiap adalah hijau
Kami benar-benar akan tidak kapal"
Itu tidak sehat baik
Dan kualitas tes
tidak selalu berkorelasi dengan pernyataan
kecuali Anda dapat mengatakan sesuatu
tentang kualitas tes Anda
hanya karena Anda telah dilaksanakan setiap baris
tidak berarti bahwa Anda telah diuji interesting kasus
Jadi, di suatu tempat di antara, Anda bisa mengatakan
"Yah, kita akan menggunakan alat-alat cakupan untuk mengidentifikasi
undertested atau buruk-diuji bagian kode
dan kita akan menggunakannya sebagai panduan
untuk mengurutkan membantu meningkatkan tingkat keyakinan keseluruhan kami"
Tapi ingat, Agile tentang merangkul perubahan
dan dealing with it
Bagian dari perubahan adalah hal-hal akan berubah yang akan menyebabkan
bug yang Anda tidak meramalkan
dan reaksi yang benar adalah:
Cukup nyaman untuk alat-alat pengujian
[hal] bahwa Anda dapat dengan cepat menemukan bug tersebut
Menulis tes yang mereproduksi bug itu
Dan kemudian membuat tes hijau
Kemudian Anda akan benar-benar memperbaikinya
Itu berarti, adalah cara yang Anda benar-benar memperbaiki bug
Jika Anda membuat tes yang benar gagal
untuk mereproduksi bug itu
dan kemudian Anda kembali dan tetap kode
untuk membuat tes lulus
Demikian pula, Anda tidak ingin mengatakan
"Yah, unit test memberi Anda lebih baik cakupan
Mereka lebih teliti dan terperinci
Jadi mari kita fokus kami pada hal itu"
sebagai lawan untuk
"Oh, fokus pada tes integrasi
karena mereka lebih realistis, kan?
Mereka mencerminkan apa yang dikatakan pelanggan yang mereka inginkan
Jadi, jika tes integrasi lewat
menurut definisi kita akan bertemu kebutuhan pelanggan"
Sekali lagi, kedua ekstrem tidak jenis sehat
karena masing-masing ini dapat menemukan masalah
yang akan dilewatkan oleh yang lain
Jadi, memiliki kombinasi yang baik dari mereka
semua jenis yang it's all about
Hal terakhir yang saya ingin meninggalkan Anda dengan adalah, aku berpikir
dalam hal pengujian, adalah "TDD versus
apa yang saya sebut konvensional debugging —
yaitu, cara bahwa kita semua jenis melakukannya
Meskipun kita berkata kita tidak"
dan kita semua mencoba untuk mendapatkan lebih baik, benar?
Kami semua jenis di selokan
Beberapa dari kami yang memandang bintang-bintang
mencoba untuk meningkatkan praktik kami
Tapi, setelah sekarang tinggal dengan ini untuk 3 atau 4 tahun sendiri
dan -aku akan jujur-3 tahun yang lalu saya tidak melakukan TDD
Saya melakukannya sekarang, karena saya menemukan bahwa lebih baik
dan di sini adalah saya distilasi mengapa saya berpikir ia bekerja untuk saya
Maaf, warna sedikit aneh
tetapi pada kolom kiri tabel
[itu] mengatakan "Konvensional debug"
dan sisi kanan mengatakan "TDD"
Jadi apa adalah cara saya gunakan untuk menulis kode?
Mungkin sebagian dari Anda masih melakukan hal ini
Aku menulis sejumlah garis
mungkin beberapa puluhan baris kode
Aku * yakin * mereka benar —
Maksudku, aku * am * programmer yang baik, benar?
Ini tidak terlalu sulit
Saya menjalankan TI-tidak bekerja
OK, api up debugger-mulai meletakkan di printf's
Jika saya telah menggunakan TDD apa yang akan saya lakukan bukan?
Yah aku akan menulis * sedikit * baris kode, setelah menulis tes pertama
Jadi segera seiring tes dari merah menjadi hijau
Aku tahu aku menulis kode yang bekerja-
atau setidaknya bagian dari perilaku yang ada dalam pikiran saya
Bagian-bagian dari perilaku bekerja, karena saya punya tes
OK, kembali ke konvensional debugging:
Aku sedang menjalankan program saya, mencoba untuk menemukan bug
Aku mulai meletakkan di printf di mana-mana
untuk mencetak nilai hal
yang dengan cara banyak menyenangkan
Ketika Anda mencoba untuk membacanya
keluar dari garis 500 log output
bahwa Anda akan mendapatkan dalam Rails app
mencoba untuk menemukan * Anda * printf's
kau tahu, "Aku tahu apa yang akan saya lakukan-
Aku akan menaruh di 75 tanda bintang sebelum dan sesudah
Yang akan membuat mudah dibaca"(tertawa)
Yang tidak-Ok, angkat tangan Anda jika Anda tidak melakukan ini!
Terima kasih atas kejujuran Anda. (tertawa) Oke.
Atau- Atau aku bisa melakukan hal yang lain, saya bisa mengatakan:
Alih-alih mencetak nilai variabel
Mengapa tidak menulis tes yang memeriksa itu
dalam sebuah harapan yang harus
dan aku akan tahu segera dalam huruf merah cerah
Jika tidak bertemu dengan harapan bahwa
OK, saya sedang kembali pada konvensional debugging sisi:
Aku keluar big guns: saya mengeluarkan Ruby debugger
Cara menetapkan debug breakpoint, dan sekarang mulai * tweaker * dan mengatakan
"Oh, mari kita lihat, aku harus bisa melewati itu pernyataan 'if'
Jadi aku harus mengatur hal itu
Oh, saya harus memanggil metode dan jadi saya perlu untuk..."
Tidak!
Aku * bisa * Sebaliknya-jika aku akan melakukan itu tetap-
Mari kita lakukan saja dalam file, mengatur beberapa mengolok-olok dan Rintisan bertopik
untuk mengontrol jalur kode, membuatnya pergi cara yang saya inginkan
Dan sekarang, "Ok, pasti aku sudah fixed it!
Aku akan mendapatkan keluar dari debugger, jalankan sekali lagi! "
Dan, tentu saja, 9 kali dari 10, Anda tidak memperbaikinya
atau Anda jenis sebagian tetap itu tetapi Anda tidak benar-benar memperbaikinya
dan sekarang saya harus melakukan semua hal-hal manual lagi
* atau * saya sudah memiliki sekelompok tes
dan jalankan saya dapat hanya kembali mereka secara otomatis
dan aku bisa, jika beberapa dari mereka gagal
"Oh, aku tidak memperbaiki semuanya
Tidak masalah, saya akan hanya pergi kembali!"
Jadi, intinya adalah bahwa
kau tahu, Anda * bisa * melakukannya di sisi kiri
tapi Anda menggunakan teknik yang sama dalam kedua kasus
Satu-satunya perbedaan adalah, dalam salah satu kasus yang Anda melakukannya secara manual
membosankan dan rawan kesalahan
Jika Anda melakukan sedikit lebih banyak pekerjaan
tapi Anda dapat membuatnya otomatis dan berulang
dan, Anda tahu, beberapa keyakinan tinggi
bahwa Anda mengubah hal-hal dalam kode Anda
Anda tidak melanggar hal-hal yang digunakan untuk bekerja
dan pada dasarnya lebih produktif
Jadi kalian semua sama hal-hal
tetapi dengan, misalnya, "delta" ekstra bekerja
Anda menggunakan usaha Anda di banyak leverage yang lebih tinggi
Jadi itu sebabnya jenis pandangan saya terhadap TDD adalah hal yang baik
Benar-benar, tidak memerlukan keterampilan baru
Ini hanya memerlukan [Anda] refactor keterampilan yang ada
Saya juga mencoba ketika saya-lagi, jujur pengakuan, kanan?-
Ketika saya mulai melakukan hal ini rasanya
"Ok, saya akan mengajar kursus di rel
Aku benar-benar harus fokus pada pengujian
Jadi aku kembali ke beberapa kode yang telah kutulis
itu * bekerja *-Anda tahu, itu layak kode-
dan aku mulai mencoba menulis tes untuk itu
dan itu * begitu menyakitkan *
karena kode tidak ditulis dalam cara yang dapat diuji
Ada semua jenis interaksi
Ada, seperti, bersarang conditional
Dan jika Anda ingin memisahkan pernyataan tertentu
dan tes-tes memicu-hanya pernyataan itu
jumlah hal-hal yang Anda harus mengatur dalam pengujian Anda
telah terjadi-
Ingat ketika berbicara tentang pura-pura kereta kecelakaan-
Anda harus mengatur semua infrastruktur ini
hanya untuk mendapatkan * satu * baris kode
dan Anda melakukan itu dan Anda pergi
"Aduh, pengujian ini benar-benar tidak layak!
Aku menulis 20 baris setup
supaya aku dapat menguji dua baris dalam fungsi saya!"
Apa yang benar-benar memberitahu Anda-seperti sekarang menyadari —
adalah fungsi Anda * buruk *
Itu adalah fungsi sangat ditulis
Hal ini tidak dapat diuji fungsi
It's got terlalu banyak bagian yang bergerak
dependensi yang * dapat Jadilah rusak
Ada tidak ada jahitan di fungsi saya
yang memungkinkan saya untuk menguji secara individual perilaku yang berbeda
Dan sekali Anda mulai melakukan tes pertama pembangunan
karena Anda harus menulis tes Anda dalam potongan kecil
itu agak membuat masalah berlalu
Sehingga telah pencerahan