WEBVTT

00:00:00.057 --> 00:00:01.092
Jadi kami menghabiskan banyak waktu

00:00:01.092 --> 00:00:03.032
dalam beberapa terakhir dari kuliah

00:00:03.032 --> 00:00:05.082
berbicara tentang berbagai jenis pengujian

00:00:05.082 --> 00:00:08.021
tentang pengujian versus integrasi pengujian unit

00:00:08.021 --> 00:00:10.010
Kami berbicara tentang bagaimana Anda menggunakan RSpec

00:00:10.010 --> 00:00:12.049
untuk benar-benar mengisolasi bagian dari kode Anda ingin menguji

00:00:12.049 --> 00:00:14.090
kau juga, Anda tahu, karena PR 3,

00:00:14.090 --> 00:00:18.017
dan hal-hal lain, kita telah melakukan BDD,

00:00:18.017 --> 00:00:20.062
di mana kita telah menggunakan mentimun untuk mengubah cerita pengguna

00:00:20.062 --> 00:00:22.095
ke dalam, pada dasarnya, integrasi dan penerimaan tes

00:00:22.095 --> 00:00:25.061
Jadi Anda telah melihat pengujian dalam beberapa tingkat yang berbeda

00:00:25.061 --> 00:00:27.063
dan tujuan di sini adalah semacam melakukan beberapa komentar

00:00:27.063 --> 00:00:29.092
kau tahu, mari kita kembali sedikit

00:00:29.092 --> 00:00:33.001
melihat gambaran besar dan mengikat hal-hal bersama-sama

00:00:33.001 --> 00:00:34.095
Jadi ini semacam meliputi bahan

00:00:34.095 --> 00:00:37.000
yang mencakup tiga atau empat bagian dalam buku

00:00:37.000 --> 00:00:39.061
dan saya ingin hanya memukul poin yang tinggi di kuliah

00:00:39.061 --> 00:00:41.046
Jadi pertanyaan yang muncul

00:00:41.046 --> 00:00:43.025
Saya yakin itu telah datang untuk kalian semua

00:00:43.025 --> 00:00:44.052
seperti yang Anda telah melakukan pekerjaan rumah

00:00:44.052 --> 00:00:45.069
adalah: "pengujian berapa banyak yang cukup?"

00:00:45.069 --> 00:00:48.049
Dan, sayangnya, untuk waktu yang lama

00:00:48.049 --> 00:00:51.009
jenis jika Anda bertanya pertanyaan ini dalam industri

00:00:51.009 --> 00:00:52.017
Jawabannya adalah pada dasarnya

00:00:52.017 --> 00:00:53.017
"Yah, kita memiliki tenggat waktu pengiriman,

00:00:53.017 --> 00:00:54.099
Jadi namun banyak pengujian dapat kita lakukan

00:00:54.099 --> 00:00:56.066
sebelum tenggat waktu itu, itu berapa banyak."

00:00:56.066 --> 00:00:58.015
Itulah apa yang Anda punya waktu untuk.

00:00:58.015 --> 00:01:00.002
Jadi, Anda tahu, itu sedikit flip

00:01:00.002 --> 00:01:01.011
jelas tidak sangat baik

00:01:01.011 --> 00:01:02.054
Sehingga Anda dapat melakukan sedikit lebih baik, kan?

00:01:02.054 --> 00:01:03.070
Ada sudah beberapa langkah-langkah yang statis

00:01:03.070 --> 00:01:06.003
seperti berapa banyak baris kode aplikasi Anda memiliki

00:01:06.003 --> 00:01:08.021
dan berapa banyak baris tes Anda punya?

00:01:08.021 --> 00:01:10.029
Dan ini bukan tidak biasa dalam industri

00:01:10.029 --> 00:01:12.068
dalam sepotong diuji dengan baik perangkat lunak

00:01:12.068 --> 00:01:14.057
untuk jumlah baris tes

00:01:14.057 --> 00:01:17.073
untuk jauh melampaui jumlah baris kode

00:01:17.073 --> 00:01:19.075
Jadi, integer kelipatan tidak biasa

00:01:19.075 --> 00:01:21.084
Dan saya pikir bahkan untuk semacam itu, Anda tahu,

00:01:21.084 --> 00:01:23.022
penelitian kode atau classwork

00:01:23.022 --> 00:01:26.085
rasio, kau tahu, mungkin 1.5 tidak masuk akal

00:01:26.085 --> 00:01:30.005
Jadi satu setengah kali jumlah tes kode

00:01:30.005 --> 00:01:32.024
karena Anda memiliki kode aplikasi

00:01:32.024 --> 00:01:34.022
Dan dalam banyak sistem produksi

00:01:34.022 --> 00:01:35.027
di mana mereka benar-benar peduli tentang pengujian

00:01:35.027 --> 00:01:36.091
Hal ini lebih tinggi dari itu

00:01:36.091 --> 00:01:38.015
Jadi mungkin pertanyaan yang lebih baik untuk bertanya:

00:01:38.015 --> 00:01:39.047
Alih-alih mengatakan "pengujian berapa banyak yang cukup?"

00:01:39.047 --> 00:01:42.049
adalah dengan bertanya "bagaimana baik adalah pengujian yang saya lakukan sekarang?

00:01:42.049 --> 00:01:44.035
Bagaimana menyeluruh itu?"

00:01:44.035 --> 00:01:45.056
Kemudian di semester ini

00:01:45.056 --> 00:01:46.056
Profesor Sen akan berbicara tentang

00:01:46.056 --> 00:01:48.018
sedikit tentang metode formal

00:01:48.018 --> 00:01:50.085
dan semacam Apakah pada batas-batas pengujian dan debugging

00:01:50.085 --> 00:01:52.068
Tetapi beberapa hal-hal yang kita dapat berbicara tentang

00:01:52.068 --> 00:01:54.007
berdasarkan apa yang Anda sudah tahu

00:01:54.007 --> 00:01:57.074
adalah beberapa konsep dasar tentang cakupan uji

00:01:57.074 --> 00:01:59.054
Dan meskipun aku akan mengatakan

00:01:59.054 --> 00:02:01.001
kau tahu, kita sudah mengatakan sepanjang

00:02:01.001 --> 00:02:03.003
metode formal, mereka tidak benar-benar bekerja pada sistem yang besar

00:02:03.003 --> 00:02:05.033
Saya pikir pernyataan itu, dalam pendapat pribadi saya

00:02:05.033 --> 00:02:07.001
benar benar-benar jauh lebih daripada dulu

00:02:07.001 --> 00:02:09.019
Saya pikir ada sejumlah tempat tertentu

00:02:09.019 --> 00:02:10.052
terutama dalam pengujian dan debugging

00:02:10.052 --> 00:02:12.084
di mana metode formal benar-benar membuat kemajuan cepat

00:02:12.084 --> 00:02:15.075
dan Koushik Sen adalah salah satu pemimpin dalam yang

00:02:15.075 --> 00:02:17.094
Sehingga Anda akan memiliki kesempatan untuk mendengar lebih banyak tentang hal ini nanti

00:02:17.094 --> 00:02:21.043
tapi untuk saat ini saya pikir, jenis roti dan mentega

00:02:21.043 --> 00:02:22.073
adalah Mari kita bicara tentang cakupan pengukuran

00:02:22.073 --> 00:02:24.047
karena ini adalah di mana karet meets the road

00:02:24.047 --> 00:02:26.020
dalam hal bagaimana Anda akan dievaluasi

00:02:26.020 --> 00:02:28.063
Jika Anda melakukan hal ini untuk real

00:02:28.063 --> 00:02:29.052
Jadi apa adalah beberapa dasar-dasar?

00:02:29.052 --> 00:02:30.078
Di sini adalah benar-benar sederhana dapat Anda gunakan

00:02:30.078 --> 00:02:32.090
untuk berbicara tentang cara yang berbeda untuk mengukur

00:02:32.090 --> 00:02:34.080
Bagaimana pengujian kami mencakup kode ini

00:02:34.080 --> 00:02:36.063
Dan ada beberapa tingkatan yang berbeda

00:02:36.063 --> 00:02:37.085
dengan terminologi yang berbeda

00:02:37.085 --> 00:02:40.073
Hal ini tidak benar-benar universal di seluruh semua rumah perangkat lunak

00:02:40.073 --> 00:02:42.064
Tapi umum satu set terminologi

00:02:42.064 --> 00:02:43.064
buku mengekspos

00:02:43.064 --> 00:02:44.068
adalah kita bisa bicara tentang S0

00:02:44.068 --> 00:02:47.045
di mana kita akan hanya berarti Anda telah dipanggil setiap metode sekali

00:02:47.045 --> 00:02:50.045
Sehingga Anda tahu, jika Anda memanggil foo, dan Anda memanggil bar, Anda sudah selesai

00:02:50.045 --> 00:02:52.015
Itulah S0 cakupan: tidak sangat menyeluruh

00:02:52.015 --> 00:02:54.068
Sedikit lebih ketat, S1, adalah

00:02:54.068 --> 00:02:56.013
Anda dapat mengatakan, kita menyebut setiap metode

00:02:56.013 --> 00:02:57.028
dari setiap tempat itu bisa disebut

00:02:57.028 --> 00:02:58.082
Jadi apa artinya itu?

00:02:58.082 --> 00:03:00.007
Itu berarti, misalnya

00:03:00.007 --> 00:03:01.012
Ianya tidak cukup untuk memanggil bar

00:03:01.012 --> 00:03:02.095
Anda harus memastikan bahwa Anda harus menyebutnya

00:03:02.095 --> 00:03:05.057
setidaknya sekali dari di sini

00:03:05.057 --> 00:03:07.016
serta menyebutnya sekali

00:03:07.016 --> 00:03:10.037
dari setiap fungsi eksterior yang mungkin menyebutnya

00:03:10.037 --> 00:03:12.081
C0 yang adalah apa yang mengukur SimpleCov

00:03:12.081 --> 00:03:15.099
(mereka yang sudah SimpleCov dan berjalan)

00:03:15.099 --> 00:03:18.052
pada dasarnya mengatakan bahwa Anda telah dilaksanakan setiap pernyataan

00:03:18.052 --> 00:03:20.004
Anda telah menyentuh setiap pernyataan dalam kode Anda sekali

00:03:20.004 --> 00:03:22.048
Tapi peringatan ada adalah bahwa

00:03:22.048 --> 00:03:25.058
conditional benar-benar hanya dihitung sebagai satu pernyataan

00:03:25.058 --> 00:03:28.091
Jadi, jika Anda, tidak peduli yang cabang ini "jika" Anda mengambil

00:03:28.091 --> 00:03:31.074
selama Anda menyentuh salah satu cabang lainnya

00:03:31.074 --> 00:03:33.035
Anda telah dieksekusi "jika ' pernyataan

00:03:33.035 --> 00:03:35.066
Jadi bahkan C0 adalah masih, Anda tahu, liputan semacam dangkal

00:03:35.066 --> 00:03:37.026
Tapi, seperti yang kita akan lihat

00:03:37.026 --> 00:03:39.023
cara bahwa Anda akan ingin untuk membaca informasi ini adalah:

00:03:39.023 --> 00:03:41.079
Jika Anda mendapatkan * buruk * cakupan setinggi C0

00:03:41.079 --> 00:03:44.007
maka Anda memiliki cakupan yang benar-benar benar-benar buruk

00:03:44.007 --> 00:03:46.008
Jadi jika Anda tidak baik membuat

00:03:46.008 --> 00:03:47.037
tingkat ini sederhana liputan dangkal

00:03:47.037 --> 00:03:50.002
maka pengujian Anda mungkin kurang

00:03:50.002 --> 00:03:51.091
C1 adalah langkah berikutnya dari itu

00:03:51.091 --> 00:03:53.071
Kita bisa mengatakan:

00:03:53.071 --> 00:03:55.019
Yah, kita harus mengambil setiap cabang di kedua arah

00:03:55.019 --> 00:03:56.061
Jadi, ketika kita melakukan pernyataan "jika" ini

00:03:56.061 --> 00:03:58.066
kita harus memastikan bahwa

00:03:58.066 --> 00:03:59.092
kita lakukan "Jika x" bagian sekali

00:03:59.092 --> 00:04:05.013
dan "jika tidak x" bagian setidaknya sekali untuk memenuhi C1

00:04:05.013 --> 00:04:08.036
Anda dapat menambah bahwa dengan keputusan cakupan

00:04:08.036 --> 00:04:09.063
berkata: Yah, kalau kita gonna…

00:04:09.063 --> 00:04:12.036
Jika kita memiliki "jika" statments di mana kondisi

00:04:12.036 --> 00:04:13.088
terdiri dari beberapa istilah

00:04:13.088 --> 00:04:15.071
kita harus memastikan bahwa setiap subexpression

00:04:15.071 --> 00:04:17.097
telah dievaluasi kedua arah

00:04:17.097 --> 00:04:19.067
Dengan kata lain, yang berarti bahwa

00:04:19.067 --> 00:04:22.041
Jika kita akan gagal pernyataan "jika" ini

00:04:22.041 --> 00:04:24.034
kita harus pastikan untuk gagal itu setidaknya sekali

00:04:24.034 --> 00:04:26.044
karena y palsu dalam sekurang-kurangnya sekali karena z palsu

00:04:26.044 --> 00:04:28.088
Dengan kata lain, setiap subexpression yang bisa

00:04:28.088 --> 00:04:31.021
independen mengubah hasil dari kondisi

00:04:31.021 --> 00:04:34.048
harus dilaksanakan di kedua arah

00:04:34.048 --> 00:04:36.003
Dan kemudian,

00:04:36.003 --> 00:04:38.052
jenis, yang itu, kau tahu, banyak orang bercita-cita untuk

00:04:38.052 --> 00:04:41.026
Namun ada ketidaksepakatan tentang berapa banyak lebih berharga itu

00:04:41.026 --> 00:04:42.083
Anda mengambil setiap jalan melalui kode

00:04:42.083 --> 00:04:45.053
Jelas, ini agak sulit karena

00:04:45.053 --> 00:04:48.033
itu cenderung menjadi eksponensial dalam beberapa kondisi

00:04:48.033 --> 00:04:53.008
Dan secara umum sulit

00:04:53.008 --> 00:04:55.031
untuk mengevaluasi jika Anda telah meluangkan setiap jalan melalui kode

00:04:55.031 --> 00:04:57.001
Ada teknik formal yang dapat Anda gunakan

00:04:57.001 --> 00:04:58.083
untuk memberitahu Anda di mana lubang

00:04:58.083 --> 00:05:01.031
tapi intinya adalah bahwa

00:05:01.031 --> 00:05:03.004
di rumah-rumah perangkat lunak komersial

00:05:03.004 --> 00:05:04.089
Aku akan berkata, tidak ada konsensus lengkap

00:05:04.089 --> 00:05:06.070
pada berapa banyak lagi berharga C2 adalah

00:05:06.070 --> 00:05:08.068
dibandingkan dengan C0 atau C1

00:05:08.068 --> 00:05:10.013
Jadi, saya kira, dengan tujuan untuk kelas kami

00:05:10.013 --> 00:05:11.067
Anda mendapatkan terpapar ide

00:05:11.067 --> 00:05:13.020
Bagaimana Anda menggunakan cakupan informasi

00:05:13.020 --> 00:05:16.040
SimpleCov mengambil keuntungan dari beberapa fitur Ruby built-in

00:05:16.040 --> 00:05:18.009
untuk memberikan C0 cakupan

00:05:18.009 --> 00:05:19.062
[Itu] tidak benar-benar baik laporan

00:05:19.062 --> 00:05:21.025
Kita bisa melihat itu semacam

00:05:21.025 --> 00:05:22.096
pada tingkat setiap baris dalam file Anda

00:05:22.096 --> 00:05:24.091
Anda dapat melihat apakah Anda cakupan

00:05:24.091 --> 00:05:27.015
dan saya rasa itulah jenis, Anda tahu

00:05:27.015 --> 00:05:31.018
awal yang baik untuk di mana kita berada

00:05:31.018 --> 00:05:33.076
Jadi, setelah melihat semacam rasa yang berbeda dari tes

00:05:33.076 --> 00:05:37.020
Melangkah mundur dan melihat kembali pada gambaran besar

00:05:37.020 --> 00:05:38.098
apa yang berbeda tes

00:05:38.098 --> 00:05:40.078
yang kita lihat secara konkret?

00:05:40.078 --> 00:05:42.032
dan apa yang dilema

00:05:42.032 --> 00:05:43.089
antara menggunakan orang-orang macam tes?

00:05:43.089 --> 00:05:47.016
Jadi kita telah melihat pada tingkat kelas individu atau metode

00:05:47.016 --> 00:05:50.009
Kami menggunakan RSpec, dengan luas penggunaan mengejek dan stubbing

00:05:50.009 --> 00:05:53.004
Jadi, misalnya ketika kita melakukan pengujian metode dalam model

00:05:53.004 --> 00:05:55.057
yang akan menjadi contoh unit testing

00:05:55.057 --> 00:05:59.025
Kami juga melakukan sesuatu yang sangat mirip dengan

00:05:59.025 --> 00:06:00.097
fungsional atau modul pengujian

00:06:00.097 --> 00:06:02.071
di mana ada lebih dari satu modul berpartisipasi

00:06:02.071 --> 00:06:04.065
Jadi, misalnya ketika kami melakukan controller spesifikasi

00:06:04.065 --> 00:06:07.085
kita melihat bahwa-kami mensimulasikan tindakan posting

00:06:07.085 --> 00:06:09.029
tapi ingat bahwa tindakan posting

00:06:09.029 --> 00:06:10.086
harus pergi melalui subsistem routing

00:06:10.086 --> 00:06:12.042
sebelum sampai ke controller

00:06:12.042 --> 00:06:14.048
Setelah controller selesai ia akan mencoba untuk membuat tampilan

00:06:14.048 --> 00:06:16.007
Jadi bahkan ada potongan lain

00:06:16.007 --> 00:06:17.067
yang berkolaborasi dengan controller

00:06:17.067 --> 00:06:19.099
yang harus bekerja dalam rangka untuk controller spesifikasi untuk lulus

00:06:19.099 --> 00:06:21.051
Jadi itu adalah suatu tempat Peralihan:

00:06:21.051 --> 00:06:23.035
di mana kami melakukan lebih dari satu metode

00:06:23.035 --> 00:06:25.000
menyentuh lebih dari satu kelas

00:06:25.000 --> 00:06:27.000
tapi kami masih berkonsentrasi perhatian [kita]

00:06:27.000 --> 00:06:28.088
di sepotong cukup sempit sistem pada satu waktu

00:06:28.088 --> 00:06:31.044
dan kami masih menggunakan mengejek dan stubbing luas

00:06:31.044 --> 00:06:35.030
untuk mengisolasi semacam itu perilaku yang kita ingin menguji

00:06:35.030 --> 00:06:36.091
Dan kemudian pada tingkat mentimun skenario

00:06:36.091 --> 00:06:38.047
ini lebih seperti integrasi atau sistem tes

00:06:38.047 --> 00:06:41.069
Mereka melaksanakan lengkap jalan di seluruh aplikasi

00:06:41.069 --> 00:06:43.044
Mereka mungkin menyentuh banyak modul yang berbeda

00:06:43.044 --> 00:06:46.003
Mereka memanfaatkan minimal mengolok-olok dan Rintisan bertopik

00:06:46.003 --> 00:06:48.032
karena bagian dari tujuan integrasi menguji

00:06:48.032 --> 00:06:50.099
Itulah untuk menguji interaksi antara lembar

00:06:50.099 --> 00:06:53.021
Jadi Anda tidak ingin tulisan rintisan atau mengontrol interaksi mereka

00:06:53.021 --> 00:06:54.080
Anda benar-benar ingin membiarkan sistem yang melakukan

00:06:54.080 --> 00:06:56.030
akan benar-benar apa

00:06:56.030 --> 00:06:58.025
Jika ini adalah skenario yang terjadi dalam produksi

00:06:58.025 --> 00:07:00.069
Jadi bagaimana kita membandingkan berbagai jenis tes?

00:07:00.069 --> 00:07:02.038
Ada beberapa sumbu yang berbeda kita dapat melihat

00:07:02.038 --> 00:07:05.007
Salah satunya adalah berapa lama mereka ambil untuk menjalankan

00:07:05.007 --> 00:07:06.090
Sekarang, RSpec dan ketimun

00:07:06.090 --> 00:07:09.013
memiliki, jenis, awal tinggi kali dan hal-hal seperti itu

00:07:09.013 --> 00:07:10.008
Tapi, seperti yang akan Anda lihat

00:07:10.008 --> 00:07:11.090
Ketika Anda mulai menambahkan lebih banyak dan lebih RSpec tes

00:07:11.090 --> 00:07:14.038
dan menggunakan autotest untuk menjalankan mereka di latar belakang

00:07:14.038 --> 00:07:17.088
pada umumnya, sekali RSpec jenis terangsang pad peluncuran

00:07:17.088 --> 00:07:19.092
membentang spesifikasi yang benar-benar cepat

00:07:19.092 --> 00:07:21.095
sedangkan menjalankan mentimun fitur hanya memakan waktu yang lama

00:07:21.095 --> 00:07:24.059
karena pada dasarnya kebakaran Anda seluruh aplikasi

00:07:24.059 --> 00:07:26.010
Dan kemudian di semester ini

00:07:26.010 --> 00:07:28.086
kita akan melihat cara untuk membuat mentimun lebih lambat-

00:07:28.086 --> 00:07:30.070
yang akan memilikinya api seluruh browser

00:07:30.070 --> 00:07:33.045
pada dasarnya bertindak seperti boneka, remote-mengendalikan Firefox

00:07:33.045 --> 00:07:35.083
Jadi Anda dapat menguji kode Javascript

00:07:35.083 --> 00:07:37.000
Kami akan melakukan bahwa ketika kita benar-benar —

00:07:37.000 --> 00:07:40.032
Saya pikir kita akan mampu bekerja dengan teman-teman kita di SourceLabs

00:07:40.032 --> 00:07:42.080
sehingga Anda dapat melakukannya di awan-yang akan menarik

00:07:42.080 --> 00:07:45.083
Jadi, "lari cepat" versus "berjalan lambat"

00:07:45.083 --> 00:07:46.068
Resolusi:

00:07:46.068 --> 00:07:48.025
Jika kesalahan terjadi di unit Anda tes

00:07:48.025 --> 00:07:49.075
Hal ini biasanya cukup mudah

00:07:49.075 --> 00:07:52.029
untuk mengetahui dan melacak apa sumber kesalahan itu adalah

00:07:52.029 --> 00:07:53.071
karena tes begitu terisolir

00:07:53.071 --> 00:07:56.025
Anda telah stubbed keluar segala sesuatu yang tidak peduli

00:07:56.025 --> 00:07:58.025
dan Anda berfokus pada hanya perilaku bunga

00:07:58.025 --> 00:07:59.076
Jadi, jika Anda telah melakukan pekerjaan yang baik melakukan hal itu

00:07:59.076 --> 00:08:01.097
ketika sesuatu yang tidak beres di salah satu tes Anda

00:08:01.097 --> 00:08:03.045
tidak ada banyak tempat

00:08:03.045 --> 00:08:04.088
itu sesuatu yang bisa pergi salah

00:08:04.088 --> 00:08:07.041
Sebaliknya, jika Anda menjalankan skenario mentimun

00:08:07.041 --> 00:08:08.089
yang punya, Anda tahu, 10 langkah

00:08:08.089 --> 00:08:10.031
dan setiap langkah menyentuh

00:08:10.031 --> 00:08:11.061
sejumlah besar potongan-potongan dari app

00:08:11.061 --> 00:08:12.091
bisa memakan waktu lama

00:08:12.091 --> 00:08:14.076
benar-benar mendapatkan ke bawah bug

00:08:14.076 --> 00:08:16.014
Jadi itu adalah jenis tradeoff

00:08:16.014 --> 00:08:17.054
antara seberapa baik dapat Anda pelokalan kesalahan

00:08:17.054 --> 00:08:20.065
Cakupan:

00:08:20.065 --> 00:08:23.002
Dimungkinkan jika Anda menulis paket yang baik

00:08:23.002 --> 00:08:24.072
unit dan tes fungsional

00:08:24.072 --> 00:08:26.020
Anda bisa mendapatkan benar-benar tinggi cakupan

00:08:26.020 --> 00:08:27.085
Anda dapat menjalankan laporan SimpleCov

00:08:27.085 --> 00:08:30.080
dan Anda dapat benar-benar mengidentifikasi baris tertentu dalam file Anda

00:08:30.080 --> 00:08:32.036
yang tidak dilaksanakan oleh tes

00:08:32.036 --> 00:08:34.016
dan kemudian Anda dapat pergi kanan di tes yang menutupi mereka

00:08:34.016 --> 00:08:36.014
Jadi, mencari tahu bagaimana untuk meningkatkan cakupan Anda

00:08:36.014 --> 00:08:37.057
misalnya di tingkat C0

00:08:37.057 --> 00:08:40.021
adalah sesuatu yang jauh lebih mudah dilakukan dengan unit test

00:08:40.021 --> 00:08:42.018
Padahal, dengan tes mentimun —

00:08:42.018 --> 00:08:43.078
dengan skenario mentimun —

00:08:43.078 --> 00:08:45.076
Anda * adalah * menyentuh banyak bagian dari kode

00:08:45.076 --> 00:08:47.080
tapi Anda melakukannya sangat jarang

00:08:47.080 --> 00:08:49.038
Jadi, jika tujuan Anda adalah untuk mendapatkan liputan Anda

00:08:49.038 --> 00:08:51.031
penggunaan alat-alat yang pada saat itu berada di tingkat unit

00:08:51.031 --> 00:08:53.007
sehingga Anda dapat berfokus pada pemahaman

00:08:53.007 --> 00:08:54.074
bagian apa atau kode saya adalah undertested

00:08:54.074 --> 00:08:56.055
dan kemudian Anda dapat menulis tes yang sangat bertarget

00:08:56.055 --> 00:08:58.086
hanya untuk fokus pada mereka

00:08:58.086 --> 00:09:01.043
Dan, semacam itu, kau tahu, menempatkan potongan-potongan bersama-sama

00:09:01.043 --> 00:09:03.039
unit test

00:09:03.039 --> 00:09:05.059
karena dari isolasi mereka dan resolusi mereka baik-baik saja

00:09:05.059 --> 00:09:07.039
cenderung menggunakan banyak mengolok-olok

00:09:07.039 --> 00:09:09.012
untuk mengisolasi perilaku Anda tidak peduli

00:09:09.012 --> 00:09:11.020
Tapi itu berarti bahwa, menurut definisi

00:09:11.020 --> 00:09:12.070
Anda tidak pengujian antarmuka

00:09:12.070 --> 00:09:14.099
dan itu adalah semacam "menerima kebijaksanaan" dalam perangkat lunak

00:09:14.099 --> 00:09:16.069
bahwa banyak menarik bug

00:09:16.069 --> 00:09:18.076
terjadi pada antarmuka antara lembar

00:09:18.076 --> 00:09:20.078
dan tidak semacam dalam kelas atau dalam metode —

00:09:20.078 --> 00:09:22.040
mereka adalah semacam bug yang mudah untuk melacak

00:09:22.040 --> 00:09:24.026
Dan pada ekstrim yang lain

00:09:24.026 --> 00:09:26.081
semakin Anda mendapatkan menuju pengujian integrasi ekstrim

00:09:26.081 --> 00:09:29.072
Kau seharusnya kurang dan kurang mengandalkan mengolok-olok

00:09:29.072 --> 00:09:30.090
untuk alasan yang tepat

00:09:30.090 --> 00:09:32.066
Sekarang kita lihat, jika Anda menguji sesuatu seperti

00:09:32.066 --> 00:09:34.015
mengatakan, dalam SOA

00:09:34.015 --> 00:09:35.089
di mana Anda harus berinteraksi dengan situs remote

00:09:35.089 --> 00:09:37.028
Anda masih berakhir

00:09:37.028 --> 00:09:38.094
harus melakukan cukup banyak mengejek dan stubbing

00:09:38.094 --> 00:09:40.028
sehingga Anda tidak bergantung pada Internet

00:09:40.028 --> 00:09:41.067
dalam rangka untuk tes Anda untuk lulus

00:09:41.067 --> 00:09:43.006
tetapi, secara umum

00:09:43.006 --> 00:09:47.014
Anda mencoba untuk menghapus sebanyak mengolok-olok yang dapat Anda

00:09:47.014 --> 00:09:48.095
dan membiarkan sistem menjalankan cara yang itu akan mencalonkan diri dalam kehidupan nyata

00:09:48.095 --> 00:09:52.070
Jadi, kabar baiknya adalah Anda * adalah * pengujian antarmuka

00:09:52.070 --> 00:09:54.074
* tapi * ketika sesuatu berjalan salah dalam salah satu antarmuka

00:09:54.074 --> 00:09:57.053
karena resolusi Anda tidak sebagus

00:09:57.053 --> 00:10:00.031
mungkin butuh waktu lebih lama untuk mencari tahu apa itu

00:10:00.031 --> 00:10:05.019
So, what's semacam sedikit tinggi urutan dari tradeoff ini

00:10:05.019 --> 00:10:07.024
Anda benar-benar tidak ingin bergantung

00:10:07.024 --> 00:10:08.076
terlalu berat pada jenis satu tes

00:10:08.076 --> 00:10:10.078
Mereka melayani tujuan yang berbeda dan, tergantung pada

00:10:10.078 --> 00:10:13.043
Apakah Anda mencoba untuk latihan Anda antarmuka yang lebih

00:10:13.043 --> 00:10:15.089
atau Anda mencoba untuk meningkatkan cakupan denda-butiran

00:10:15.089 --> 00:10:18.003
yang mempengaruhi bagaimana Anda mengembangkan test suite

00:10:18.003 --> 00:10:20.065
dan Anda akan berkembang bersama dengan perangkat lunak Anda

00:10:20.065 --> 00:10:24.014
Jadi, kami telah menggunakan serangkaian terminologi dalam pengujian

00:10:24.014 --> 00:10:26.028
Ini adalah istilah yang, oleh dan besar

00:10:26.028 --> 00:10:29.001
ini paling sering digunakan dalam komunitas Rails

00:10:29.001 --> 00:10:30.060
tetapi ada beberapa variasi

00:10:30.060 --> 00:10:33.069
[dan] beberapa istilah lain bahwa Anda mungkin mendengar

00:10:33.069 --> 00:10:35.018
Jika Anda pergi mendapatkan pekerjaan di suatu tempat

00:10:35.018 --> 00:10:36.093
dan Anda mendengar tentang mutasi pengujian

00:10:36.093 --> 00:10:38.072
yang belum kita lakukan

00:10:38.072 --> 00:10:40.024
Ini adalah ide yang menarik, saya pikir, diciptakan oleh

00:10:40.024 --> 00:10:43.037
Ammann dan Offutt, yang memiliki, semacam

00:10:43.037 --> 00:10:44.093
buku definitif pengujian perangkat lunak

00:10:44.093 --> 00:10:46.048
Idenya adalah:

00:10:46.048 --> 00:10:48.000
Kira saya memperkenalkan bug yang disengaja ke kode saya

00:10:48.000 --> 00:10:49.051
Apakah yang memaksa beberapa tes gagal?

00:10:49.051 --> 00:10:53.003
Karena, jika aku berubah, Anda tahu, "Jika x" untuk "jika tidak x"

00:10:53.003 --> 00:10:56.010
dan tidak ada tes gagal, maka baik aku kehilangan beberapa liputan

00:10:56.010 --> 00:10:59.019
atau saya app sangat aneh dan entah bagaimana nondeterministic

00:10:59.019 --> 00:11:03.099
Fuzz pengujian, yang Koushik Sen mungkin berbicara lebih banyak tentang

00:11:03.099 --> 00:11:07.085
pada dasarnya, ini adalah "10.000 monyet di mesin tik

00:11:07.085 --> 00:11:09.024
melemparkan masukan acak pada kode Anda"

00:11:09.024 --> 00:11:10.037
Apa yang menarik tentang hal itu adalah bahwa

00:11:10.037 --> 00:11:11.065
Kami telah melakukan tes

00:11:11.065 --> 00:11:13.086
pada dasarnya yang dibuat untuk menguji app

00:11:13.086 --> 00:11:15.058
Cara dirancang

00:11:15.058 --> 00:11:16.088
dan ini, Anda tahu, fuzz pengujian

00:11:16.088 --> 00:11:19.064
tentang pengujian app dalam cara itu * tidak * dimaksudkan untuk digunakan

00:11:19.064 --> 00:11:22.098
Jadi, apa yang terjadi jika Anda melempar pengiriman form besar

00:11:22.098 --> 00:11:25.036
Apa yang terjadi jika Anda meletakkan kontrol karakter dalam bentuk Anda?

00:11:25.036 --> 00:11:27.062
Apa yang terjadi jika Anda mengirimkan hal yang sama berulang-ulang?

00:11:27.062 --> 00:11:29.093
Dan, Koushik memiliki statistik yang

00:11:29.093 --> 00:11:32.033
Microsoft menemukan hingga 20% bug mereka

00:11:32.033 --> 00:11:34.064
menggunakan beberapa variasi fuzz pengujian

00:11:34.064 --> 00:11:36.029
dan sekitar 25 %

00:11:36.029 --> 00:11:39.021
Program baris perintah Unix yang umum

00:11:39.021 --> 00:11:40.092
dapat dibuat untuk crash

00:11:40.092 --> 00:11:44.018
[ketika] menempatkan melalui agresif fuzz pengujian

00:11:44.018 --> 00:11:46.089
Penggunaan mendefinisikan cakupan adalah sesuatu yang belum kita lakukan

00:11:46.089 --> 00:11:48.089
tapi itu adalah konsep menarik lain

00:11:48.089 --> 00:11:50.089
Idenya adalah bahwa pada setiap titik dalam program saya

00:11:50.089 --> 00:11:52.062
ada tempat di mana aku mendefinisikan —

00:11:52.062 --> 00:11:54.046
atau saya menetapkan nilai ke beberapa variabel-

00:11:54.046 --> 00:11:56.000
dan kemudian ada tempat Hilir

00:11:56.000 --> 00:11:57.075
di mana mungkin aku akan mengkonsumsi nilai-

00:11:57.075 --> 00:11:59.058
seseorang akan menggunakan nilai tersebut

00:11:59.058 --> 00:12:01.013
Memiliki aku menutupi setiap pasangan?

00:12:01.013 --> 00:12:02.059
Dengan kata lain, punya tes di mana setiap pasangan

00:12:02.059 --> 00:12:04.054
mendefinisikan variabel dan menggunakannya di suatu tempat

00:12:04.054 --> 00:12:07.014
dieksekusi di beberapa bagian dari test suites

00:12:07.014 --> 00:12:10.071
Kadang-kadang disebut DU-cakupan

00:12:10.071 --> 00:12:14.011
Dan ketentuan lain yang saya pikir tidak secara luas digunakan lagi

00:12:14.011 --> 00:12:17.071
BlackBox versus whitebox, atau blackbox versus glassbox

00:12:17.071 --> 00:12:20.025
Secara kasar, tes blackbox adalah salah satu yang ditulis dari

00:12:20.025 --> 00:12:22.041
sudut pandang spesifikasi eksternal yang

00:12:22.041 --> 00:12:24.022
[Misalnya:] "Ini adalah tabel hash

00:12:24.022 --> 00:12:26.015
Ketika saya meletakkan di kunci saya harus mendapatkan kembali nilai

00:12:26.015 --> 00:12:28.011
Jika saya menghapus kunci nilai boleh ada"

00:12:28.011 --> 00:12:29.099
Itu adalah tes blackbox karena ia tidak mengatakan

00:12:29.099 --> 00:12:32.028
apa-apa tentang bagaimana tabel hash diimplementasikan

00:12:32.028 --> 00:12:34.072
dan tidak mencoba untuk stres pelaksanaan

00:12:34.072 --> 00:12:36.056
Tes whitebox sesuai mungkin:

00:12:36.056 --> 00:12:38.008
"Aku tahu sesuatu tentang fungsi hash

00:12:38.008 --> 00:12:39.098
dan aku akan untuk sengaja menciptakan

00:12:39.098 --> 00:12:41.088
kunci Hash di saya uji kasus

00:12:41.088 --> 00:12:43.078
yang menyebabkan banyak hash tabrakan

00:12:43.078 --> 00:12:45.095
untuk memastikan bahwa aku pengujian bagian fungsi"

00:12:45.095 --> 00:12:49.007
Sekarang, C0 tes cakupan alat, seperti SimpleCov

00:12:49.007 --> 00:12:52.001
akan mengungkapkan bahwa jika semua yang Anda miliki adalah blackbox tes

00:12:52.001 --> 00:12:53.028
Anda mungkin menemukan bahwa

00:12:53.028 --> 00:12:55.056
kode cakupan tabrakan tidak dipukul sangat sering

00:12:55.056 --> 00:12:56.075
Dan yang mungkin Anda tip off mengatakan:

00:12:56.075 --> 00:12:58.028
"Ok, jika benar-benar ingin untuk memperkuat bahwa-

00:12:58.028 --> 00:13:00.008
untuk satu, jika saya ingin meningkatkan cakupan untuk tes

00:13:00.008 --> 00:13:02.006
Sekarang aku harus menulis whitebox atau tes glassbox

00:13:02.006 --> 00:13:04.057
Aku harus melihat ke dalam, melihat apa pelaksanaan

00:13:04.057 --> 00:13:05.061
dan menemukan cara-cara khusus

00:13:05.061 --> 00:13:10.060
untuk mencoba memecahkan pelaksanaan dalam cara-cara jahat"

00:13:10.060 --> 00:13:13.075
Jadi, saya pikir, pengujian semacam cara hidup, benar?

00:13:13.075 --> 00:13:16.069
Kita sudah jauh dari tahap

00:13:16.069 --> 00:13:18.033
"Kita akan membangun semuanya dan kemudian kami akan menguji it"

00:13:18.033 --> 00:13:19.092
dan kita sudah ke tahap

00:13:19.092 --> 00:13:20.077
"Kami sedang menguji sebagai kita pergi"

00:13:20.077 --> 00:13:22.048
Pengujian benar-benar lebih mirip sebuah alat pengembangan

00:13:22.048 --> 00:13:24.022
dan seperti begitu banyak alat-alat pengembangan

00:13:24.022 --> 00:13:25.062
efektivitas itu tergantung

00:13:25.062 --> 00:13:27.013
pada apakah Anda menggunakannya dalam cara yang gurih

00:13:27.013 --> 00:13:31.002
Jadi, Anda bisa mengatakan: "Yah, mari kita lihat-saya menendang ban

00:13:31.002 --> 00:13:33.048
Kau tahu, aku bersemangat browser, saya mencoba beberapa hal

00:13:33.048 --> 00:13:35.097
(tepuk tangan tangan) Tampak seperti itu bekerja! Menyebarkan!"

00:13:35.097 --> 00:13:38.045
Itulah jelas cavalier lebih sedikit daripada yang Anda ingin menjadi

00:13:38.045 --> 00:13:41.024
Dan, omong-omong, salah satu hal yang kami menemukan

00:13:41.024 --> 00:13:43.077
dengan kursus online ini hanya memulai

00:13:43.077 --> 00:13:45.090
Ketika 60.000 orang terdaftar dalam kursus

00:13:45.090 --> 00:13:48.099
dan 0,1% dari orang-orang memiliki masalah

00:13:48.099 --> 00:13:50.083
Anda akan mendapatkan email 60

00:13:50.083 --> 00:13:53.078
Wajar adalah: bila situs Anda digunakan oleh banyak orang

00:13:53.078 --> 00:13:55.089
beberapa bug bodoh bahwa Anda tidak menemukan

00:13:55.089 --> 00:13:57.018
tapi yang bisa ditemukan dengan menguji

00:13:57.018 --> 00:13:59.080
bisa sangat cepat menghasilkan * banyak * sakit

00:13:59.080 --> 00:14:02.023
Di sisi lain, Anda tidak ingin dogmatis dan mengatakan

00:14:02.023 --> 00:14:04.056
"Eh, sampai kami punya 100% cakupan dan menguji setiap adalah hijau

00:14:04.056 --> 00:14:06.005
Kami benar-benar akan tidak kapal"

00:14:06.005 --> 00:14:07.012
Itu tidak sehat baik

00:14:07.012 --> 00:14:08.048
Dan kualitas tes

00:14:08.048 --> 00:14:10.057
tidak selalu berkorelasi dengan pernyataan

00:14:10.057 --> 00:14:11.064
kecuali Anda dapat mengatakan sesuatu

00:14:11.064 --> 00:14:12.068
tentang kualitas tes Anda

00:14:12.068 --> 00:14:14.029
hanya karena Anda telah dilaksanakan setiap baris

00:14:14.029 --> 00:14:17.010
tidak berarti bahwa Anda telah diuji interesting kasus

00:14:17.010 --> 00:14:18.068
Jadi, di suatu tempat di antara, Anda bisa mengatakan

00:14:18.068 --> 00:14:20.014
"Yah, kita akan menggunakan alat-alat cakupan untuk mengidentifikasi

00:14:20.014 --> 00:14:23.004
undertested atau buruk-diuji bagian kode

00:14:23.004 --> 00:14:24.073
dan kita akan menggunakannya sebagai panduan

00:14:24.073 --> 00:14:27.011
untuk mengurutkan membantu meningkatkan tingkat keyakinan keseluruhan kami"

00:14:27.011 --> 00:14:29.024
Tapi ingat, Agile tentang merangkul perubahan

00:14:29.024 --> 00:14:30.032
dan dealing with it

00:14:30.032 --> 00:14:32.002
Bagian dari perubahan adalah hal-hal akan berubah yang akan menyebabkan

00:14:32.002 --> 00:14:33.038
bug yang Anda tidak meramalkan

00:14:33.038 --> 00:14:34.031
dan reaksi yang benar adalah:

00:14:34.031 --> 00:14:36.026
Cukup nyaman untuk alat-alat pengujian

00:14:36.026 --> 00:14:37.064
[hal] bahwa Anda dapat dengan cepat menemukan bug tersebut

00:14:37.064 --> 00:14:39.025
Menulis tes yang mereproduksi bug itu

00:14:39.025 --> 00:14:40.062
Dan kemudian membuat tes hijau

00:14:40.062 --> 00:14:41.061
Kemudian Anda akan benar-benar memperbaikinya

00:14:41.061 --> 00:14:43.004
Itu berarti, adalah cara yang Anda benar-benar memperbaiki bug

00:14:43.004 --> 00:14:45.049
Jika Anda membuat tes yang benar gagal

00:14:45.049 --> 00:14:46.088
untuk mereproduksi bug itu

00:14:46.088 --> 00:14:48.055
dan kemudian Anda kembali dan tetap kode

00:14:48.055 --> 00:14:49.057
untuk membuat tes lulus

00:14:49.057 --> 00:14:51.073
Demikian pula, Anda tidak ingin mengatakan

00:14:51.073 --> 00:14:53.036
"Yah, unit test memberi Anda lebih baik cakupan

00:14:53.036 --> 00:14:54.073
Mereka lebih teliti dan terperinci

00:14:54.073 --> 00:14:56.044
Jadi mari kita fokus kami pada hal itu"

00:14:56.044 --> 00:14:57.062
sebagai lawan untuk

00:14:57.062 --> 00:14:58.093
"Oh, fokus pada tes integrasi

00:14:58.093 --> 00:15:00.006
karena mereka lebih realistis, kan?

00:15:00.006 --> 00:15:01.056
Mereka mencerminkan apa yang dikatakan pelanggan yang mereka inginkan

00:15:01.056 --> 00:15:03.034
Jadi, jika tes integrasi lewat

00:15:03.034 --> 00:15:05.067
menurut definisi kita akan bertemu kebutuhan pelanggan"

00:15:05.067 --> 00:15:07.034
Sekali lagi, kedua ekstrem tidak jenis sehat

00:15:07.034 --> 00:15:09.079
karena masing-masing ini dapat menemukan masalah

00:15:09.079 --> 00:15:11.031
yang akan dilewatkan oleh yang lain

00:15:11.031 --> 00:15:12.060
Jadi, memiliki kombinasi yang baik dari mereka

00:15:12.060 --> 00:15:15.042
semua jenis yang it's all about

00:15:15.042 --> 00:15:18.072
Hal terakhir yang saya ingin meninggalkan Anda dengan adalah, aku berpikir

00:15:18.072 --> 00:15:20.036
dalam hal pengujian, adalah "TDD versus

00:15:20.036 --> 00:15:22.005
apa yang saya sebut konvensional debugging —

00:15:22.005 --> 00:15:24.004
yaitu, cara bahwa kita semua jenis melakukannya

00:15:24.004 --> 00:15:25.051
Meskipun kita berkata kita tidak"

00:15:25.051 --> 00:15:26.064
dan kita semua mencoba untuk mendapatkan lebih baik, benar?

00:15:26.064 --> 00:15:27.085
Kami semua jenis di selokan

00:15:27.085 --> 00:15:29.036
Beberapa dari kami yang memandang bintang-bintang

00:15:29.036 --> 00:15:31.011
mencoba untuk meningkatkan praktik kami

00:15:31.011 --> 00:15:33.099
Tapi, setelah sekarang tinggal dengan ini untuk 3 atau 4 tahun sendiri

00:15:33.099 --> 00:15:35.091
dan -aku akan jujur-3 tahun yang lalu saya tidak melakukan TDD

00:15:35.091 --> 00:15:37.079
Saya melakukannya sekarang, karena saya menemukan bahwa lebih baik

00:15:37.079 --> 00:15:40.081
dan di sini adalah saya distilasi mengapa saya berpikir ia bekerja untuk saya

00:15:40.081 --> 00:15:43.032
Maaf, warna sedikit aneh

00:15:43.032 --> 00:15:45.000
tetapi pada kolom kiri tabel

00:15:45.000 --> 00:15:46.034
[itu] mengatakan "Konvensional debug"

00:15:46.034 --> 00:15:47.044
dan sisi kanan mengatakan "TDD"

00:15:47.044 --> 00:15:49.069
Jadi apa adalah cara saya gunakan untuk menulis kode?

00:15:49.069 --> 00:15:51.056
Mungkin sebagian dari Anda masih melakukan hal ini

00:15:51.056 --> 00:15:53.013
Aku menulis sejumlah garis

00:15:53.013 --> 00:15:54.043
mungkin beberapa puluhan baris kode

00:15:54.043 --> 00:15:55.059
Aku * yakin * mereka benar —

00:15:55.059 --> 00:15:56.061
Maksudku, aku * am * programmer yang baik, benar?

00:15:56.061 --> 00:15:57.099
Ini tidak terlalu sulit

00:15:57.099 --> 00:15:59.002
Saya menjalankan TI-tidak bekerja

00:15:59.002 --> 00:16:01.098
OK, api up debugger-mulai meletakkan di printf's

00:16:01.098 --> 00:16:04.088
Jika saya telah menggunakan TDD apa yang akan saya lakukan bukan?

00:16:04.088 --> 00:16:08.022
Yah aku akan menulis * sedikit * baris kode, setelah menulis tes pertama

00:16:08.022 --> 00:16:10.071
Jadi segera seiring tes dari merah menjadi hijau

00:16:10.071 --> 00:16:12.064
Aku tahu aku menulis kode yang bekerja-

00:16:12.064 --> 00:16:15.013
atau setidaknya bagian dari perilaku yang ada dalam pikiran saya

00:16:15.013 --> 00:16:16.096
Bagian-bagian dari perilaku bekerja, karena saya punya tes

00:16:16.096 --> 00:16:19.056
OK, kembali ke konvensional debugging:

00:16:19.056 --> 00:16:21.073
Aku sedang menjalankan program saya, mencoba untuk menemukan bug

00:16:21.073 --> 00:16:23.028
Aku mulai meletakkan di printf di mana-mana

00:16:23.028 --> 00:16:24.062
untuk mencetak nilai hal

00:16:24.062 --> 00:16:25.064
yang dengan cara banyak menyenangkan

00:16:25.064 --> 00:16:26.073
Ketika Anda mencoba untuk membacanya

00:16:26.073 --> 00:16:28.014
keluar dari garis 500 log output

00:16:28.014 --> 00:16:29.035
bahwa Anda akan mendapatkan dalam Rails app

00:16:29.035 --> 00:16:30.087
mencoba untuk menemukan * Anda * printf's

00:16:30.087 --> 00:16:32.035
kau tahu, "Aku tahu apa yang akan saya lakukan-

00:16:32.035 --> 00:16:34.008
Aku akan menaruh di 75 tanda bintang sebelum dan sesudah

00:16:34.008 --> 00:16:36.043
Yang akan membuat mudah dibaca"(tertawa)

00:16:36.043 --> 00:16:38.071
Yang tidak-Ok, angkat tangan Anda jika Anda tidak melakukan ini!

00:16:38.071 --> 00:16:40.090
Terima kasih atas kejujuran Anda. (tertawa) Oke.

00:16:40.090 --> 00:16:43.014
Atau- Atau aku bisa melakukan hal yang lain, saya bisa mengatakan:

00:16:43.014 --> 00:16:45.030
Alih-alih mencetak nilai variabel

00:16:45.030 --> 00:16:47.039
Mengapa tidak menulis tes yang memeriksa itu

00:16:47.039 --> 00:16:48.079
dalam sebuah harapan yang harus

00:16:48.079 --> 00:16:50.090
dan aku akan tahu segera dalam huruf merah cerah

00:16:50.090 --> 00:16:53.033
Jika tidak bertemu dengan harapan bahwa

00:16:53.033 --> 00:16:56.005
OK, saya sedang kembali pada konvensional debugging sisi:

00:16:56.005 --> 00:16:58.090
Aku keluar big guns: saya mengeluarkan Ruby debugger

00:16:58.092 --> 00:17:02.044
Cara menetapkan debug breakpoint, dan sekarang mulai * tweaker * dan mengatakan

00:17:02.044 --> 00:17:04.085
"Oh, mari kita lihat, aku harus bisa melewati itu pernyataan 'if'

00:17:04.085 --> 00:17:06.002
Jadi aku harus mengatur hal itu

00:17:06.002 --> 00:17:07.063
Oh, saya harus memanggil metode dan jadi saya perlu untuk..."

00:17:07.063 --> 00:17:08.065
Tidak!

00:17:08.065 --> 00:17:10.087
Aku * bisa * Sebaliknya-jika aku akan melakukan itu tetap-

00:17:10.087 --> 00:17:13.000
Mari kita lakukan saja dalam file, mengatur beberapa mengolok-olok dan Rintisan bertopik

00:17:13.000 --> 00:17:16.045
untuk mengontrol jalur kode, membuatnya pergi cara yang saya inginkan

00:17:16.045 --> 00:17:19.013
Dan sekarang, "Ok, pasti aku sudah fixed it!

00:17:19.013 --> 00:17:22.012
Aku akan mendapatkan keluar dari debugger, jalankan sekali lagi! "

00:17:22.012 --> 00:17:24.022
Dan, tentu saja, 9 kali dari 10, Anda tidak memperbaikinya

00:17:24.022 --> 00:17:26.072
atau Anda jenis sebagian tetap itu tetapi Anda tidak benar-benar memperbaikinya

00:17:26.072 --> 00:17:30.040
dan sekarang saya harus melakukan semua hal-hal manual lagi

00:17:30.040 --> 00:17:32.086
* atau * saya sudah memiliki sekelompok tes

00:17:32.086 --> 00:17:34.031
dan jalankan saya dapat hanya kembali mereka secara otomatis

00:17:34.031 --> 00:17:35.056
dan aku bisa, jika beberapa dari mereka gagal

00:17:35.056 --> 00:17:36.087
"Oh, aku tidak memperbaiki semuanya

00:17:36.087 --> 00:17:38.040
Tidak masalah, saya akan hanya pergi kembali!"

00:17:38.040 --> 00:17:39.096
Jadi, intinya adalah bahwa

00:17:39.096 --> 00:17:41.095
kau tahu, Anda * bisa * melakukannya di sisi kiri

00:17:41.095 --> 00:17:45.004
tapi Anda menggunakan teknik yang sama dalam kedua kasus

00:17:45.004 --> 00:17:48.062
Satu-satunya perbedaan adalah, dalam salah satu kasus yang Anda melakukannya secara manual

00:17:48.062 --> 00:17:50.004
membosankan dan rawan kesalahan

00:17:50.004 --> 00:17:51.078
Jika Anda melakukan sedikit lebih banyak pekerjaan

00:17:51.078 --> 00:17:53.095
tapi Anda dapat membuatnya otomatis dan berulang

00:17:53.095 --> 00:17:55.071
dan, Anda tahu, beberapa keyakinan tinggi

00:17:55.071 --> 00:17:57.003
bahwa Anda mengubah hal-hal dalam kode Anda

00:17:57.003 --> 00:17:58.092
Anda tidak melanggar hal-hal yang digunakan untuk bekerja

00:17:58.092 --> 00:18:00.091
dan pada dasarnya lebih produktif

00:18:00.091 --> 00:18:02.047
Jadi kalian semua sama hal-hal

00:18:02.047 --> 00:18:04.037
tetapi dengan, misalnya, "delta" ekstra bekerja

00:18:04.037 --> 00:18:07.086
Anda menggunakan usaha Anda di banyak leverage yang lebih tinggi

00:18:07.086 --> 00:18:10.036
Jadi itu sebabnya jenis pandangan saya terhadap TDD adalah hal yang baik

00:18:10.036 --> 00:18:11.088
Benar-benar, tidak memerlukan keterampilan baru

00:18:11.088 --> 00:18:15.011
Ini hanya memerlukan [Anda] refactor keterampilan yang ada

00:18:15.011 --> 00:18:18.014
Saya juga mencoba ketika saya-lagi, jujur pengakuan, kanan?-

00:18:18.014 --> 00:18:19.034
Ketika saya mulai melakukan hal ini rasanya

00:18:19.034 --> 00:18:21.049
"Ok, saya akan mengajar kursus di rel

00:18:21.049 --> 00:18:22.065
Aku benar-benar harus fokus pada pengujian

00:18:22.065 --> 00:18:24.032
Jadi aku kembali ke beberapa kode yang telah kutulis

00:18:24.032 --> 00:18:26.087
itu * bekerja *-Anda tahu, itu layak kode-

00:18:26.087 --> 00:18:29.006
dan aku mulai mencoba menulis tes untuk itu

00:18:29.006 --> 00:18:31.019
dan itu * begitu menyakitkan *

00:18:31.019 --> 00:18:33.033
karena kode tidak ditulis dalam cara yang dapat diuji

00:18:33.033 --> 00:18:34.097
Ada semua jenis interaksi

00:18:34.097 --> 00:18:36.038
Ada, seperti, bersarang conditional

00:18:36.038 --> 00:18:38.083
Dan jika Anda ingin memisahkan pernyataan tertentu

00:18:38.083 --> 00:18:41.070
dan tes-tes memicu-hanya pernyataan itu

00:18:41.070 --> 00:18:44.000
jumlah hal-hal yang Anda harus mengatur dalam pengujian Anda

00:18:44.000 --> 00:18:45.009
telah terjadi-

00:18:45.009 --> 00:18:46.040
Ingat ketika berbicara tentang pura-pura kereta kecelakaan-

00:18:46.040 --> 00:18:48.014
Anda harus mengatur semua infrastruktur ini

00:18:48.014 --> 00:18:49.063
hanya untuk mendapatkan * satu * baris kode

00:18:49.063 --> 00:18:51.015
dan Anda melakukan itu dan Anda pergi

00:18:51.015 --> 00:18:52.074
"Aduh, pengujian ini benar-benar tidak layak!

00:18:52.074 --> 00:18:54.034
Aku menulis 20 baris setup

00:18:54.034 --> 00:18:56.059
supaya aku dapat menguji dua baris dalam fungsi saya!"

00:18:56.059 --> 00:18:58.085
Apa yang benar-benar memberitahu Anda-seperti sekarang menyadari —

00:18:58.085 --> 00:19:00.042
adalah fungsi Anda * buruk *

00:19:00.042 --> 00:19:01.049
Itu adalah fungsi sangat ditulis

00:19:01.049 --> 00:19:02.052
Hal ini tidak dapat diuji fungsi

00:19:02.052 --> 00:19:03.088
It's got terlalu banyak bagian yang bergerak

00:19:03.088 --> 00:19:06.026
dependensi yang * dapat Jadilah rusak

00:19:06.026 --> 00:19:07.070
Ada tidak ada jahitan di fungsi saya

00:19:07.070 --> 00:19:11.008
yang memungkinkan saya untuk menguji secara individual perilaku yang berbeda

00:19:11.008 --> 00:19:12.083
Dan sekali Anda mulai melakukan tes pertama pembangunan

00:19:12.083 --> 00:19:15.043
karena Anda harus menulis tes Anda dalam potongan kecil

00:19:15.043 --> 00:19:17.053
itu agak membuat masalah berlalu

00:19:17.053 --> 99:59:59.999
Sehingga telah pencerahan