5.8 - 5.11 - Coverage, Unit vs. Integration Tests, Other Testing Concepts, and Perspectives

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