0:00:00.057,0:00:01.092
Jadi kami menghabiskan banyak waktu

0:00:01.092,0:00:03.032
dalam beberapa terakhir dari kuliah

0:00:03.032,0:00:05.082
berbicara tentang berbagai jenis pengujian

0:00:05.082,0:00:08.021
tentang pengujian versus integrasi pengujian unit

0:00:08.021,0:00:10.010
Kami berbicara tentang bagaimana Anda menggunakan RSpec

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

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

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

0:00:18.017,0:00:20.062
di mana kita telah menggunakan mentimun untuk mengubah cerita pengguna

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

0:00:22.095,0:00:25.061
Jadi Anda telah melihat pengujian dalam beberapa tingkat yang berbeda

0:00:25.061,0:00:27.063
dan tujuan di sini adalah semacam melakukan beberapa komentar

0:00:27.063,0:00:29.092
kau tahu, mari kita kembali sedikit

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

0:00:33.001,0:00:34.095
Jadi ini semacam meliputi bahan

0:00:34.095,0:00:37.000
yang mencakup tiga atau empat bagian dalam buku

0:00:37.000,0:00:39.061
dan saya ingin hanya memukul poin yang tinggi di kuliah

0:00:39.061,0:00:41.046
Jadi pertanyaan yang muncul

0:00:41.046,0:00:43.025
Saya yakin itu telah datang untuk kalian semua

0:00:43.025,0:00:44.052
seperti yang Anda telah melakukan pekerjaan rumah

0:00:44.052,0:00:45.069
adalah: "pengujian berapa banyak yang cukup?"

0:00:45.069,0:00:48.049
Dan, sayangnya, untuk waktu yang lama

0:00:48.049,0:00:51.009
jenis jika Anda bertanya pertanyaan ini dalam industri

0:00:51.009,0:00:52.017
Jawabannya adalah pada dasarnya

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

0:00:53.017,0:00:54.099
Jadi namun banyak pengujian dapat kita lakukan

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

0:00:56.066,0:00:58.015
Itulah apa yang Anda punya waktu untuk.

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

0:01:00.002,0:01:01.011
jelas tidak sangat baik

0:01:01.011,0:01:02.054
Sehingga Anda dapat melakukan sedikit lebih baik, kan?

0:01:02.054,0:01:03.070
Ada sudah beberapa langkah-langkah yang statis

0:01:03.070,0:01:06.003
seperti berapa banyak baris kode aplikasi Anda memiliki

0:01:06.003,0:01:08.021
dan berapa banyak baris tes Anda punya?

0:01:08.021,0:01:10.029
Dan ini bukan tidak biasa dalam industri

0:01:10.029,0:01:12.068
dalam sepotong diuji dengan baik perangkat lunak

0:01:12.068,0:01:14.057
untuk jumlah baris tes

0:01:14.057,0:01:17.073
untuk jauh melampaui jumlah baris kode

0:01:17.073,0:01:19.075
Jadi, integer kelipatan tidak biasa

0:01:19.075,0:01:21.084
Dan saya pikir bahkan untuk semacam itu, Anda tahu,

0:01:21.084,0:01:23.022
penelitian kode atau classwork

0:01:23.022,0:01:26.085
rasio, kau tahu, mungkin 1.5 tidak masuk akal

0:01:26.085,0:01:30.005
Jadi satu setengah kali jumlah tes kode

0:01:30.005,0:01:32.024
karena Anda memiliki kode aplikasi

0:01:32.024,0:01:34.022
Dan dalam banyak sistem produksi

0:01:34.022,0:01:35.027
di mana mereka benar-benar peduli tentang pengujian

0:01:35.027,0:01:36.091
Hal ini lebih tinggi dari itu

0:01:36.091,0:01:38.015
Jadi mungkin pertanyaan yang lebih baik untuk bertanya:

0:01:38.015,0:01:39.047
Alih-alih mengatakan "pengujian berapa banyak yang cukup?"

0:01:39.047,0:01:42.049
adalah dengan bertanya "bagaimana baik adalah pengujian yang saya lakukan sekarang?

0:01:42.049,0:01:44.035
Bagaimana menyeluruh itu?"

0:01:44.035,0:01:45.056
Kemudian di semester ini

0:01:45.056,0:01:46.056
Profesor Sen akan berbicara tentang

0:01:46.056,0:01:48.018
sedikit tentang metode formal

0:01:48.018,0:01:50.085
dan semacam Apakah pada batas-batas pengujian dan debugging

0:01:50.085,0:01:52.068
Tetapi beberapa hal-hal yang kita dapat berbicara tentang

0:01:52.068,0:01:54.007
berdasarkan apa yang Anda sudah tahu

0:01:54.007,0:01:57.074
adalah beberapa konsep dasar tentang cakupan uji

0:01:57.074,0:01:59.054
Dan meskipun aku akan mengatakan

0:01:59.054,0:02:01.001
kau tahu, kita sudah mengatakan sepanjang

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

0:02:03.003,0:02:05.033
Saya pikir pernyataan itu, dalam pendapat pribadi saya

0:02:05.033,0:02:07.001
benar benar-benar jauh lebih daripada dulu

0:02:07.001,0:02:09.019
Saya pikir ada sejumlah tempat tertentu

0:02:09.019,0:02:10.052
terutama dalam pengujian dan debugging

0:02:10.052,0:02:12.084
di mana metode formal benar-benar membuat kemajuan cepat

0:02:12.084,0:02:15.075
dan Koushik Sen adalah salah satu pemimpin dalam yang

0:02:15.075,0:02:17.094
Sehingga Anda akan memiliki kesempatan untuk mendengar lebih banyak tentang hal ini nanti

0:02:17.094,0:02:21.043
tapi untuk saat ini saya pikir, jenis roti dan mentega

0:02:21.043,0:02:22.073
adalah Mari kita bicara tentang cakupan pengukuran

0:02:22.073,0:02:24.047
karena ini adalah di mana karet meets the road

0:02:24.047,0:02:26.020
dalam hal bagaimana Anda akan dievaluasi

0:02:26.020,0:02:28.063
Jika Anda melakukan hal ini untuk real

0:02:28.063,0:02:29.052
Jadi apa adalah beberapa dasar-dasar?

0:02:29.052,0:02:30.078
Di sini adalah benar-benar sederhana dapat Anda gunakan

0:02:30.078,0:02:32.090
untuk berbicara tentang cara yang berbeda untuk mengukur

0:02:32.090,0:02:34.080
Bagaimana pengujian kami mencakup kode ini

0:02:34.080,0:02:36.063
Dan ada beberapa tingkatan yang berbeda

0:02:36.063,0:02:37.085
dengan terminologi yang berbeda

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

0:02:40.073,0:02:42.064
Tapi umum satu set terminologi

0:02:42.064,0:02:43.064
buku mengekspos

0:02:43.064,0:02:44.068
adalah kita bisa bicara tentang S0

0:02:44.068,0:02:47.045
di mana kita akan hanya berarti Anda telah dipanggil setiap metode sekali

0:02:47.045,0:02:50.045
Sehingga Anda tahu, jika Anda memanggil foo, dan Anda memanggil bar, Anda sudah selesai

0:02:50.045,0:02:52.015
Itulah S0 cakupan: tidak sangat menyeluruh

0:02:52.015,0:02:54.068
Sedikit lebih ketat, S1, adalah

0:02:54.068,0:02:56.013
Anda dapat mengatakan, kita menyebut setiap metode

0:02:56.013,0:02:57.028
dari setiap tempat itu bisa disebut

0:02:57.028,0:02:58.082
Jadi apa artinya itu?

0:02:58.082,0:03:00.007
Itu berarti, misalnya

0:03:00.007,0:03:01.012
Ianya tidak cukup untuk memanggil bar

0:03:01.012,0:03:02.095
Anda harus memastikan bahwa Anda harus menyebutnya

0:03:02.095,0:03:05.057
setidaknya sekali dari di sini

0:03:05.057,0:03:07.016
serta menyebutnya sekali

0:03:07.016,0:03:10.037
dari setiap fungsi eksterior yang mungkin menyebutnya

0:03:10.037,0:03:12.081
C0 yang adalah apa yang mengukur SimpleCov

0:03:12.081,0:03:15.099
(mereka yang sudah SimpleCov dan berjalan)

0:03:15.099,0:03:18.052
pada dasarnya mengatakan bahwa Anda telah dilaksanakan setiap pernyataan

0:03:18.052,0:03:20.004
Anda telah menyentuh setiap pernyataan dalam kode Anda sekali

0:03:20.004,0:03:22.048
Tapi peringatan ada adalah bahwa

0:03:22.048,0:03:25.058
conditional benar-benar hanya dihitung sebagai satu pernyataan

0:03:25.058,0:03:28.091
Jadi, jika Anda, tidak peduli yang cabang ini "jika" Anda mengambil

0:03:28.091,0:03:31.074
selama Anda menyentuh salah satu cabang lainnya

0:03:31.074,0:03:33.035
Anda telah dieksekusi "jika ' pernyataan

0:03:33.035,0:03:35.066
Jadi bahkan C0 adalah masih, Anda tahu, liputan semacam dangkal

0:03:35.066,0:03:37.026
Tapi, seperti yang kita akan lihat

0:03:37.026,0:03:39.023
cara bahwa Anda akan ingin untuk membaca informasi ini adalah:

0:03:39.023,0:03:41.079
Jika Anda mendapatkan * buruk * cakupan setinggi C0

0:03:41.079,0:03:44.007
maka Anda memiliki cakupan yang benar-benar benar-benar buruk

0:03:44.007,0:03:46.008
Jadi jika Anda tidak baik membuat

0:03:46.008,0:03:47.037
tingkat ini sederhana liputan dangkal

0:03:47.037,0:03:50.002
maka pengujian Anda mungkin kurang

0:03:50.002,0:03:51.091
C1 adalah langkah berikutnya dari itu

0:03:51.091,0:03:53.071
Kita bisa mengatakan:

0:03:53.071,0:03:55.019
Yah, kita harus mengambil setiap cabang di kedua arah

0:03:55.019,0:03:56.061
Jadi, ketika kita melakukan pernyataan "jika" ini

0:03:56.061,0:03:58.066
kita harus memastikan bahwa

0:03:58.066,0:03:59.092
kita lakukan "Jika x" bagian sekali

0:03:59.092,0:04:05.013
dan "jika tidak x" bagian setidaknya sekali untuk memenuhi C1

0:04:05.013,0:04:08.036
Anda dapat menambah bahwa dengan keputusan cakupan

0:04:08.036,0:04:09.063
berkata: Yah, kalau kita gonna…

0:04:09.063,0:04:12.036
Jika kita memiliki "jika" statments di mana kondisi

0:04:12.036,0:04:13.088
terdiri dari beberapa istilah

0:04:13.088,0:04:15.071
kita harus memastikan bahwa setiap subexpression

0:04:15.071,0:04:17.097
telah dievaluasi kedua arah

0:04:17.097,0:04:19.067
Dengan kata lain, yang berarti bahwa

0:04:19.067,0:04:22.041
Jika kita akan gagal pernyataan "jika" ini

0:04:22.041,0:04:24.034
kita harus pastikan untuk gagal itu setidaknya sekali

0:04:24.034,0:04:26.044
karena y palsu dalam sekurang-kurangnya sekali karena z palsu

0:04:26.044,0:04:28.088
Dengan kata lain, setiap subexpression yang bisa

0:04:28.088,0:04:31.021
independen mengubah hasil dari kondisi

0:04:31.021,0:04:34.048
harus dilaksanakan di kedua arah

0:04:34.048,0:04:36.003
Dan kemudian,

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

0:04:38.052,0:04:41.026
Namun ada ketidaksepakatan tentang berapa banyak lebih berharga itu

0:04:41.026,0:04:42.083
Anda mengambil setiap jalan melalui kode

0:04:42.083,0:04:45.053
Jelas, ini agak sulit karena

0:04:45.053,0:04:48.033
itu cenderung menjadi eksponensial dalam beberapa kondisi

0:04:48.033,0:04:53.008
Dan secara umum sulit

0:04:53.008,0:04:55.031
untuk mengevaluasi jika Anda telah meluangkan setiap jalan melalui kode

0:04:55.031,0:04:57.001
Ada teknik formal yang dapat Anda gunakan

0:04:57.001,0:04:58.083
untuk memberitahu Anda di mana lubang

0:04:58.083,0:05:01.031
tapi intinya adalah bahwa

0:05:01.031,0:05:03.004
di rumah-rumah perangkat lunak komersial

0:05:03.004,0:05:04.089
Aku akan berkata, tidak ada konsensus lengkap

0:05:04.089,0:05:06.070
pada berapa banyak lagi berharga C2 adalah

0:05:06.070,0:05:08.068
dibandingkan dengan C0 atau C1

0:05:08.068,0:05:10.013
Jadi, saya kira, dengan tujuan untuk kelas kami

0:05:10.013,0:05:11.067
Anda mendapatkan terpapar ide

0:05:11.067,0:05:13.020
Bagaimana Anda menggunakan cakupan informasi

0:05:13.020,0:05:16.040
SimpleCov mengambil keuntungan dari beberapa fitur Ruby built-in

0:05:16.040,0:05:18.009
untuk memberikan C0 cakupan

0:05:18.009,0:05:19.062
[Itu] tidak benar-benar baik laporan

0:05:19.062,0:05:21.025
Kita bisa melihat itu semacam

0:05:21.025,0:05:22.096
pada tingkat setiap baris dalam file Anda

0:05:22.096,0:05:24.091
Anda dapat melihat apakah Anda cakupan

0:05:24.091,0:05:27.015
dan saya rasa itulah jenis, Anda tahu

0:05:27.015,0:05:31.018
awal yang baik untuk di mana kita berada

0:05:31.018,0:05:33.076
Jadi, setelah melihat semacam rasa yang berbeda dari tes

0:05:33.076,0:05:37.020
Melangkah mundur dan melihat kembali pada gambaran besar

0:05:37.020,0:05:38.098
apa yang berbeda tes

0:05:38.098,0:05:40.078
yang kita lihat secara konkret?

0:05:40.078,0:05:42.032
dan apa yang dilema

0:05:42.032,0:05:43.089
antara menggunakan orang-orang macam tes?

0:05:43.089,0:05:47.016
Jadi kita telah melihat pada tingkat kelas individu atau metode

0:05:47.016,0:05:50.009
Kami menggunakan RSpec, dengan luas penggunaan mengejek dan stubbing

0:05:50.009,0:05:53.004
Jadi, misalnya ketika kita melakukan pengujian metode dalam model

0:05:53.004,0:05:55.057
yang akan menjadi contoh unit testing

0:05:55.057,0:05:59.025
Kami juga melakukan sesuatu yang sangat mirip dengan

0:05:59.025,0:06:00.097
fungsional atau modul pengujian

0:06:00.097,0:06:02.071
di mana ada lebih dari satu modul berpartisipasi

0:06:02.071,0:06:04.065
Jadi, misalnya ketika kami melakukan controller spesifikasi

0:06:04.065,0:06:07.085
kita melihat bahwa-kami mensimulasikan tindakan posting

0:06:07.085,0:06:09.029
tapi ingat bahwa tindakan posting

0:06:09.029,0:06:10.086
harus pergi melalui subsistem routing

0:06:10.086,0:06:12.042
sebelum sampai ke controller

0:06:12.042,0:06:14.048
Setelah controller selesai ia akan mencoba untuk membuat tampilan

0:06:14.048,0:06:16.007
Jadi bahkan ada potongan lain

0:06:16.007,0:06:17.067
yang berkolaborasi dengan controller

0:06:17.067,0:06:19.099
yang harus bekerja dalam rangka untuk controller spesifikasi untuk lulus

0:06:19.099,0:06:21.051
Jadi itu adalah suatu tempat Peralihan:

0:06:21.051,0:06:23.035
di mana kami melakukan lebih dari satu metode

0:06:23.035,0:06:25.000
menyentuh lebih dari satu kelas

0:06:25.000,0:06:27.000
tapi kami masih berkonsentrasi perhatian [kita]

0:06:27.000,0:06:28.088
di sepotong cukup sempit sistem pada satu waktu

0:06:28.088,0:06:31.044
dan kami masih menggunakan mengejek dan stubbing luas

0:06:31.044,0:06:35.030
untuk mengisolasi semacam itu perilaku yang kita ingin menguji

0:06:35.030,0:06:36.091
Dan kemudian pada tingkat mentimun skenario

0:06:36.091,0:06:38.047
ini lebih seperti integrasi atau sistem tes

0:06:38.047,0:06:41.069
Mereka melaksanakan lengkap jalan di seluruh aplikasi

0:06:41.069,0:06:43.044
Mereka mungkin menyentuh banyak modul yang berbeda

0:06:43.044,0:06:46.003
Mereka memanfaatkan minimal mengolok-olok dan Rintisan bertopik

0:06:46.003,0:06:48.032
karena bagian dari tujuan integrasi menguji

0:06:48.032,0:06:50.099
Itulah untuk menguji interaksi antara lembar

0:06:50.099,0:06:53.021
Jadi Anda tidak ingin tulisan rintisan atau mengontrol interaksi mereka

0:06:53.021,0:06:54.080
Anda benar-benar ingin membiarkan sistem yang melakukan

0:06:54.080,0:06:56.030
akan benar-benar apa

0:06:56.030,0:06:58.025
Jika ini adalah skenario yang terjadi dalam produksi

0:06:58.025,0:07:00.069
Jadi bagaimana kita membandingkan berbagai jenis tes?

0:07:00.069,0:07:02.038
Ada beberapa sumbu yang berbeda kita dapat melihat

0:07:02.038,0:07:05.007
Salah satunya adalah berapa lama mereka ambil untuk menjalankan

0:07:05.007,0:07:06.090
Sekarang, RSpec dan ketimun

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

0:07:09.013,0:07:10.008
Tapi, seperti yang akan Anda lihat

0:07:10.008,0:07:11.090
Ketika Anda mulai menambahkan lebih banyak dan lebih RSpec tes

0:07:11.090,0:07:14.038
dan menggunakan autotest untuk menjalankan mereka di latar belakang

0:07:14.038,0:07:17.088
pada umumnya, sekali RSpec jenis terangsang pad peluncuran

0:07:17.088,0:07:19.092
membentang spesifikasi yang benar-benar cepat

0:07:19.092,0:07:21.095
sedangkan menjalankan mentimun fitur hanya memakan waktu yang lama

0:07:21.095,0:07:24.059
karena pada dasarnya kebakaran Anda seluruh aplikasi

0:07:24.059,0:07:26.010
Dan kemudian di semester ini

0:07:26.010,0:07:28.086
kita akan melihat cara untuk membuat mentimun lebih lambat-

0:07:28.086,0:07:30.070
yang akan memilikinya api seluruh browser

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

0:07:33.045,0:07:35.083
Jadi Anda dapat menguji kode Javascript

0:07:35.083,0:07:37.000
Kami akan melakukan bahwa ketika kita benar-benar —

0:07:37.000,0:07:40.032
Saya pikir kita akan mampu bekerja dengan teman-teman kita di SourceLabs

0:07:40.032,0:07:42.080
sehingga Anda dapat melakukannya di awan-yang akan menarik

0:07:42.080,0:07:45.083
Jadi, "lari cepat" versus "berjalan lambat"

0:07:45.083,0:07:46.068
Resolusi:

0:07:46.068,0:07:48.025
Jika kesalahan terjadi di unit Anda tes

0:07:48.025,0:07:49.075
Hal ini biasanya cukup mudah

0:07:49.075,0:07:52.029
untuk mengetahui dan melacak apa sumber kesalahan itu adalah

0:07:52.029,0:07:53.071
karena tes begitu terisolir

0:07:53.071,0:07:56.025
Anda telah stubbed keluar segala sesuatu yang tidak peduli

0:07:56.025,0:07:58.025
dan Anda berfokus pada hanya perilaku bunga

0:07:58.025,0:07:59.076
Jadi, jika Anda telah melakukan pekerjaan yang baik melakukan hal itu

0:07:59.076,0:08:01.097
ketika sesuatu yang tidak beres di salah satu tes Anda

0:08:01.097,0:08:03.045
tidak ada banyak tempat

0:08:03.045,0:08:04.088
itu sesuatu yang bisa pergi salah

0:08:04.088,0:08:07.041
Sebaliknya, jika Anda menjalankan skenario mentimun

0:08:07.041,0:08:08.089
yang punya, Anda tahu, 10 langkah

0:08:08.089,0:08:10.031
dan setiap langkah menyentuh

0:08:10.031,0:08:11.061
sejumlah besar potongan-potongan dari app

0:08:11.061,0:08:12.091
bisa memakan waktu lama

0:08:12.091,0:08:14.076
benar-benar mendapatkan ke bawah bug

0:08:14.076,0:08:16.014
Jadi itu adalah jenis tradeoff

0:08:16.014,0:08:17.054
antara seberapa baik dapat Anda pelokalan kesalahan

0:08:17.054,0:08:20.065
Cakupan:

0:08:20.065,0:08:23.002
Dimungkinkan jika Anda menulis paket yang baik

0:08:23.002,0:08:24.072
unit dan tes fungsional

0:08:24.072,0:08:26.020
Anda bisa mendapatkan benar-benar tinggi cakupan

0:08:26.020,0:08:27.085
Anda dapat menjalankan laporan SimpleCov

0:08:27.085,0:08:30.080
dan Anda dapat benar-benar mengidentifikasi baris tertentu dalam file Anda

0:08:30.080,0:08:32.036
yang tidak dilaksanakan oleh tes

0:08:32.036,0:08:34.016
dan kemudian Anda dapat pergi kanan di tes yang menutupi mereka

0:08:34.016,0:08:36.014
Jadi, mencari tahu bagaimana untuk meningkatkan cakupan Anda

0:08:36.014,0:08:37.057
misalnya di tingkat C0

0:08:37.057,0:08:40.021
adalah sesuatu yang jauh lebih mudah dilakukan dengan unit test

0:08:40.021,0:08:42.018
Padahal, dengan tes mentimun —

0:08:42.018,0:08:43.078
dengan skenario mentimun —

0:08:43.078,0:08:45.076
Anda * adalah * menyentuh banyak bagian dari kode

0:08:45.076,0:08:47.080
tapi Anda melakukannya sangat jarang

0:08:47.080,0:08:49.038
Jadi, jika tujuan Anda adalah untuk mendapatkan liputan Anda

0:08:49.038,0:08:51.031
penggunaan alat-alat yang pada saat itu berada di tingkat unit

0:08:51.031,0:08:53.007
sehingga Anda dapat berfokus pada pemahaman

0:08:53.007,0:08:54.074
bagian apa atau kode saya adalah undertested

0:08:54.074,0:08:56.055
dan kemudian Anda dapat menulis tes yang sangat bertarget

0:08:56.055,0:08:58.086
hanya untuk fokus pada mereka

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

0:09:01.043,0:09:03.039
unit test

0:09:03.039,0:09:05.059
karena dari isolasi mereka dan resolusi mereka baik-baik saja

0:09:05.059,0:09:07.039
cenderung menggunakan banyak mengolok-olok

0:09:07.039,0:09:09.012
untuk mengisolasi perilaku Anda tidak peduli

0:09:09.012,0:09:11.020
Tapi itu berarti bahwa, menurut definisi

0:09:11.020,0:09:12.070
Anda tidak pengujian antarmuka

0:09:12.070,0:09:14.099
dan itu adalah semacam "menerima kebijaksanaan" dalam perangkat lunak

0:09:14.099,0:09:16.069
bahwa banyak menarik bug

0:09:16.069,0:09:18.076
terjadi pada antarmuka antara lembar

0:09:18.076,0:09:20.078
dan tidak semacam dalam kelas atau dalam metode —

0:09:20.078,0:09:22.040
mereka adalah semacam bug yang mudah untuk melacak

0:09:22.040,0:09:24.026
Dan pada ekstrim yang lain

0:09:24.026,0:09:26.081
semakin Anda mendapatkan menuju pengujian integrasi ekstrim

0:09:26.081,0:09:29.072
Kau seharusnya kurang dan kurang mengandalkan mengolok-olok

0:09:29.072,0:09:30.090
untuk alasan yang tepat

0:09:30.090,0:09:32.066
Sekarang kita lihat, jika Anda menguji sesuatu seperti

0:09:32.066,0:09:34.015
mengatakan, dalam SOA

0:09:34.015,0:09:35.089
di mana Anda harus berinteraksi dengan situs remote

0:09:35.089,0:09:37.028
Anda masih berakhir

0:09:37.028,0:09:38.094
harus melakukan cukup banyak mengejek dan stubbing

0:09:38.094,0:09:40.028
sehingga Anda tidak bergantung pada Internet

0:09:40.028,0:09:41.067
dalam rangka untuk tes Anda untuk lulus

0:09:41.067,0:09:43.006
tetapi, secara umum

0:09:43.006,0:09:47.014
Anda mencoba untuk menghapus sebanyak mengolok-olok yang dapat Anda

0:09:47.014,0:09:48.095
dan membiarkan sistem menjalankan cara yang itu akan mencalonkan diri dalam kehidupan nyata

0:09:48.095,0:09:52.070
Jadi, kabar baiknya adalah Anda * adalah * pengujian antarmuka

0:09:52.070,0:09:54.074
* tapi * ketika sesuatu berjalan salah dalam salah satu antarmuka

0:09:54.074,0:09:57.053
karena resolusi Anda tidak sebagus

0:09:57.053,0:10:00.031
mungkin butuh waktu lebih lama untuk mencari tahu apa itu

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

0:10:05.019,0:10:07.024
Anda benar-benar tidak ingin bergantung

0:10:07.024,0:10:08.076
terlalu berat pada jenis satu tes

0:10:08.076,0:10:10.078
Mereka melayani tujuan yang berbeda dan, tergantung pada

0:10:10.078,0:10:13.043
Apakah Anda mencoba untuk latihan Anda antarmuka yang lebih

0:10:13.043,0:10:15.089
atau Anda mencoba untuk meningkatkan cakupan denda-butiran

0:10:15.089,0:10:18.003
yang mempengaruhi bagaimana Anda mengembangkan test suite

0:10:18.003,0:10:20.065
dan Anda akan berkembang bersama dengan perangkat lunak Anda

0:10:20.065,0:10:24.014
Jadi, kami telah menggunakan serangkaian terminologi dalam pengujian

0:10:24.014,0:10:26.028
Ini adalah istilah yang, oleh dan besar

0:10:26.028,0:10:29.001
ini paling sering digunakan dalam komunitas Rails

0:10:29.001,0:10:30.060
tetapi ada beberapa variasi

0:10:30.060,0:10:33.069
[dan] beberapa istilah lain bahwa Anda mungkin mendengar

0:10:33.069,0:10:35.018
Jika Anda pergi mendapatkan pekerjaan di suatu tempat

0:10:35.018,0:10:36.093
dan Anda mendengar tentang mutasi pengujian

0:10:36.093,0:10:38.072
yang belum kita lakukan

0:10:38.072,0:10:40.024
Ini adalah ide yang menarik, saya pikir, diciptakan oleh

0:10:40.024,0:10:43.037
Ammann dan Offutt, yang memiliki, semacam

0:10:43.037,0:10:44.093
buku definitif pengujian perangkat lunak

0:10:44.093,0:10:46.048
Idenya adalah:

0:10:46.048,0:10:48.000
Kira saya memperkenalkan bug yang disengaja ke kode saya

0:10:48.000,0:10:49.051
Apakah yang memaksa beberapa tes gagal?

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

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

0:10:56.010,0:10:59.019
atau saya app sangat aneh dan entah bagaimana nondeterministic

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

0:11:03.099,0:11:07.085
pada dasarnya, ini adalah "10.000 monyet di mesin tik

0:11:07.085,0:11:09.024
melemparkan masukan acak pada kode Anda"

0:11:09.024,0:11:10.037
Apa yang menarik tentang hal itu adalah bahwa

0:11:10.037,0:11:11.065
Kami telah melakukan tes

0:11:11.065,0:11:13.086
pada dasarnya yang dibuat untuk menguji app

0:11:13.086,0:11:15.058
Cara dirancang

0:11:15.058,0:11:16.088
dan ini, Anda tahu, fuzz pengujian

0:11:16.088,0:11:19.064
tentang pengujian app dalam cara itu * tidak * dimaksudkan untuk digunakan

0:11:19.064,0:11:22.098
Jadi, apa yang terjadi jika Anda melempar pengiriman form besar

0:11:22.098,0:11:25.036
Apa yang terjadi jika Anda meletakkan kontrol karakter dalam bentuk Anda?

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

0:11:27.062,0:11:29.093
Dan, Koushik memiliki statistik yang

0:11:29.093,0:11:32.033
Microsoft menemukan hingga 20% bug mereka

0:11:32.033,0:11:34.064
menggunakan beberapa variasi fuzz pengujian

0:11:34.064,0:11:36.029
dan sekitar 25 %

0:11:36.029,0:11:39.021
Program baris perintah Unix yang umum

0:11:39.021,0:11:40.092
dapat dibuat untuk crash

0:11:40.092,0:11:44.018
[ketika] menempatkan melalui agresif fuzz pengujian

0:11:44.018,0:11:46.089
Penggunaan mendefinisikan cakupan adalah sesuatu yang belum kita lakukan

0:11:46.089,0:11:48.089
tapi itu adalah konsep menarik lain

0:11:48.089,0:11:50.089
Idenya adalah bahwa pada setiap titik dalam program saya

0:11:50.089,0:11:52.062
ada tempat di mana aku mendefinisikan —

0:11:52.062,0:11:54.046
atau saya menetapkan nilai ke beberapa variabel-

0:11:54.046,0:11:56.000
dan kemudian ada tempat Hilir

0:11:56.000,0:11:57.075
di mana mungkin aku akan mengkonsumsi nilai-

0:11:57.075,0:11:59.058
seseorang akan menggunakan nilai tersebut

0:11:59.058,0:12:01.013
Memiliki aku menutupi setiap pasangan?

0:12:01.013,0:12:02.059
Dengan kata lain, punya tes di mana setiap pasangan

0:12:02.059,0:12:04.054
mendefinisikan variabel dan menggunakannya di suatu tempat

0:12:04.054,0:12:07.014
dieksekusi di beberapa bagian dari test suites

0:12:07.014,0:12:10.071
Kadang-kadang disebut DU-cakupan

0:12:10.071,0:12:14.011
Dan ketentuan lain yang saya pikir tidak secara luas digunakan lagi

0:12:14.011,0:12:17.071
BlackBox versus whitebox, atau blackbox versus glassbox

0:12:17.071,0:12:20.025
Secara kasar, tes blackbox adalah salah satu yang ditulis dari

0:12:20.025,0:12:22.041
sudut pandang spesifikasi eksternal yang

0:12:22.041,0:12:24.022
[Misalnya:] "Ini adalah tabel hash

0:12:24.022,0:12:26.015
Ketika saya meletakkan di kunci saya harus mendapatkan kembali nilai

0:12:26.015,0:12:28.011
Jika saya menghapus kunci nilai boleh ada"

0:12:28.011,0:12:29.099
Itu adalah tes blackbox karena ia tidak mengatakan

0:12:29.099,0:12:32.028
apa-apa tentang bagaimana tabel hash diimplementasikan

0:12:32.028,0:12:34.072
dan tidak mencoba untuk stres pelaksanaan

0:12:34.072,0:12:36.056
Tes whitebox sesuai mungkin:

0:12:36.056,0:12:38.008
"Aku tahu sesuatu tentang fungsi hash

0:12:38.008,0:12:39.098
dan aku akan untuk sengaja menciptakan

0:12:39.098,0:12:41.088
kunci Hash di saya uji kasus

0:12:41.088,0:12:43.078
yang menyebabkan banyak hash tabrakan

0:12:43.078,0:12:45.095
untuk memastikan bahwa aku pengujian bagian fungsi"

0:12:45.095,0:12:49.007
Sekarang, C0 tes cakupan alat, seperti SimpleCov

0:12:49.007,0:12:52.001
akan mengungkapkan bahwa jika semua yang Anda miliki adalah blackbox tes

0:12:52.001,0:12:53.028
Anda mungkin menemukan bahwa

0:12:53.028,0:12:55.056
kode cakupan tabrakan tidak dipukul sangat sering

0:12:55.056,0:12:56.075
Dan yang mungkin Anda tip off mengatakan:

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

0:12:58.028,0:13:00.008
untuk satu, jika saya ingin meningkatkan cakupan untuk tes

0:13:00.008,0:13:02.006
Sekarang aku harus menulis whitebox atau tes glassbox

0:13:02.006,0:13:04.057
Aku harus melihat ke dalam, melihat apa pelaksanaan

0:13:04.057,0:13:05.061
dan menemukan cara-cara khusus

0:13:05.061,0:13:10.060
untuk mencoba memecahkan pelaksanaan dalam cara-cara jahat"

0:13:10.060,0:13:13.075
Jadi, saya pikir, pengujian semacam cara hidup, benar?

0:13:13.075,0:13:16.069
Kita sudah jauh dari tahap

0:13:16.069,0:13:18.033
"Kita akan membangun semuanya dan kemudian kami akan menguji it"

0:13:18.033,0:13:19.092
dan kita sudah ke tahap

0:13:19.092,0:13:20.077
"Kami sedang menguji sebagai kita pergi"

0:13:20.077,0:13:22.048
Pengujian benar-benar lebih mirip sebuah alat pengembangan

0:13:22.048,0:13:24.022
dan seperti begitu banyak alat-alat pengembangan

0:13:24.022,0:13:25.062
efektivitas itu tergantung

0:13:25.062,0:13:27.013
pada apakah Anda menggunakannya dalam cara yang gurih

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

0:13:31.002,0:13:33.048
Kau tahu, aku bersemangat browser, saya mencoba beberapa hal

0:13:33.048,0:13:35.097
(tepuk tangan tangan) Tampak seperti itu bekerja! Menyebarkan!"

0:13:35.097,0:13:38.045
Itulah jelas cavalier lebih sedikit daripada yang Anda ingin menjadi

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

0:13:41.024,0:13:43.077
dengan kursus online ini hanya memulai

0:13:43.077,0:13:45.090
Ketika 60.000 orang terdaftar dalam kursus

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

0:13:48.099,0:13:50.083
Anda akan mendapatkan email 60

0:13:50.083,0:13:53.078
Wajar adalah: bila situs Anda digunakan oleh banyak orang

0:13:53.078,0:13:55.089
beberapa bug bodoh bahwa Anda tidak menemukan

0:13:55.089,0:13:57.018
tapi yang bisa ditemukan dengan menguji

0:13:57.018,0:13:59.080
bisa sangat cepat menghasilkan * banyak * sakit

0:13:59.080,0:14:02.023
Di sisi lain, Anda tidak ingin dogmatis dan mengatakan

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

0:14:04.056,0:14:06.005
Kami benar-benar akan tidak kapal"

0:14:06.005,0:14:07.012
Itu tidak sehat baik

0:14:07.012,0:14:08.048
Dan kualitas tes

0:14:08.048,0:14:10.057
tidak selalu berkorelasi dengan pernyataan

0:14:10.057,0:14:11.064
kecuali Anda dapat mengatakan sesuatu

0:14:11.064,0:14:12.068
tentang kualitas tes Anda

0:14:12.068,0:14:14.029
hanya karena Anda telah dilaksanakan setiap baris

0:14:14.029,0:14:17.010
tidak berarti bahwa Anda telah diuji interesting kasus

0:14:17.010,0:14:18.068
Jadi, di suatu tempat di antara, Anda bisa mengatakan

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

0:14:20.014,0:14:23.004
undertested atau buruk-diuji bagian kode

0:14:23.004,0:14:24.073
dan kita akan menggunakannya sebagai panduan

0:14:24.073,0:14:27.011
untuk mengurutkan membantu meningkatkan tingkat keyakinan keseluruhan kami"

0:14:27.011,0:14:29.024
Tapi ingat, Agile tentang merangkul perubahan

0:14:29.024,0:14:30.032
dan dealing with it

0:14:30.032,0:14:32.002
Bagian dari perubahan adalah hal-hal akan berubah yang akan menyebabkan

0:14:32.002,0:14:33.038
bug yang Anda tidak meramalkan

0:14:33.038,0:14:34.031
dan reaksi yang benar adalah:

0:14:34.031,0:14:36.026
Cukup nyaman untuk alat-alat pengujian

0:14:36.026,0:14:37.064
[hal] bahwa Anda dapat dengan cepat menemukan bug tersebut

0:14:37.064,0:14:39.025
Menulis tes yang mereproduksi bug itu

0:14:39.025,0:14:40.062
Dan kemudian membuat tes hijau

0:14:40.062,0:14:41.061
Kemudian Anda akan benar-benar memperbaikinya

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

0:14:43.004,0:14:45.049
Jika Anda membuat tes yang benar gagal

0:14:45.049,0:14:46.088
untuk mereproduksi bug itu

0:14:46.088,0:14:48.055
dan kemudian Anda kembali dan tetap kode

0:14:48.055,0:14:49.057
untuk membuat tes lulus

0:14:49.057,0:14:51.073
Demikian pula, Anda tidak ingin mengatakan

0:14:51.073,0:14:53.036
"Yah, unit test memberi Anda lebih baik cakupan

0:14:53.036,0:14:54.073
Mereka lebih teliti dan terperinci

0:14:54.073,0:14:56.044
Jadi mari kita fokus kami pada hal itu"

0:14:56.044,0:14:57.062
sebagai lawan untuk

0:14:57.062,0:14:58.093
"Oh, fokus pada tes integrasi

0:14:58.093,0:15:00.006
karena mereka lebih realistis, kan?

0:15:00.006,0:15:01.056
Mereka mencerminkan apa yang dikatakan pelanggan yang mereka inginkan

0:15:01.056,0:15:03.034
Jadi, jika tes integrasi lewat

0:15:03.034,0:15:05.067
menurut definisi kita akan bertemu kebutuhan pelanggan"

0:15:05.067,0:15:07.034
Sekali lagi, kedua ekstrem tidak jenis sehat

0:15:07.034,0:15:09.079
karena masing-masing ini dapat menemukan masalah

0:15:09.079,0:15:11.031
yang akan dilewatkan oleh yang lain

0:15:11.031,0:15:12.060
Jadi, memiliki kombinasi yang baik dari mereka

0:15:12.060,0:15:15.042
semua jenis yang it's all about

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

0:15:18.072,0:15:20.036
dalam hal pengujian, adalah "TDD versus

0:15:20.036,0:15:22.005
apa yang saya sebut konvensional debugging —

0:15:22.005,0:15:24.004
yaitu, cara bahwa kita semua jenis melakukannya

0:15:24.004,0:15:25.051
Meskipun kita berkata kita tidak"

0:15:25.051,0:15:26.064
dan kita semua mencoba untuk mendapatkan lebih baik, benar?

0:15:26.064,0:15:27.085
Kami semua jenis di selokan

0:15:27.085,0:15:29.036
Beberapa dari kami yang memandang bintang-bintang

0:15:29.036,0:15:31.011
mencoba untuk meningkatkan praktik kami

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

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

0:15:35.091,0:15:37.079
Saya melakukannya sekarang, karena saya menemukan bahwa lebih baik

0:15:37.079,0:15:40.081
dan di sini adalah saya distilasi mengapa saya berpikir ia bekerja untuk saya

0:15:40.081,0:15:43.032
Maaf, warna sedikit aneh

0:15:43.032,0:15:45.000
tetapi pada kolom kiri tabel

0:15:45.000,0:15:46.034
[itu] mengatakan "Konvensional debug"

0:15:46.034,0:15:47.044
dan sisi kanan mengatakan "TDD"

0:15:47.044,0:15:49.069
Jadi apa adalah cara saya gunakan untuk menulis kode?

0:15:49.069,0:15:51.056
Mungkin sebagian dari Anda masih melakukan hal ini

0:15:51.056,0:15:53.013
Aku menulis sejumlah garis

0:15:53.013,0:15:54.043
mungkin beberapa puluhan baris kode

0:15:54.043,0:15:55.059
Aku * yakin * mereka benar —

0:15:55.059,0:15:56.061
Maksudku, aku * am * programmer yang baik, benar?

0:15:56.061,0:15:57.099
Ini tidak terlalu sulit

0:15:57.099,0:15:59.002
Saya menjalankan TI-tidak bekerja

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

0:16:01.098,0:16:04.088
Jika saya telah menggunakan TDD apa yang akan saya lakukan bukan?

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

0:16:08.022,0:16:10.071
Jadi segera seiring tes dari merah menjadi hijau

0:16:10.071,0:16:12.064
Aku tahu aku menulis kode yang bekerja-

0:16:12.064,0:16:15.013
atau setidaknya bagian dari perilaku yang ada dalam pikiran saya

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

0:16:16.096,0:16:19.056
OK, kembali ke konvensional debugging:

0:16:19.056,0:16:21.073
Aku sedang menjalankan program saya, mencoba untuk menemukan bug

0:16:21.073,0:16:23.028
Aku mulai meletakkan di printf di mana-mana

0:16:23.028,0:16:24.062
untuk mencetak nilai hal

0:16:24.062,0:16:25.064
yang dengan cara banyak menyenangkan

0:16:25.064,0:16:26.073
Ketika Anda mencoba untuk membacanya

0:16:26.073,0:16:28.014
keluar dari garis 500 log output

0:16:28.014,0:16:29.035
bahwa Anda akan mendapatkan dalam Rails app

0:16:29.035,0:16:30.087
mencoba untuk menemukan * Anda * printf's

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

0:16:32.035,0:16:34.008
Aku akan menaruh di 75 tanda bintang sebelum dan sesudah

0:16:34.008,0:16:36.043
Yang akan membuat mudah dibaca"(tertawa)

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

0:16:38.071,0:16:40.090
Terima kasih atas kejujuran Anda. (tertawa) Oke.

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

0:16:43.014,0:16:45.030
Alih-alih mencetak nilai variabel

0:16:45.030,0:16:47.039
Mengapa tidak menulis tes yang memeriksa itu

0:16:47.039,0:16:48.079
dalam sebuah harapan yang harus

0:16:48.079,0:16:50.090
dan aku akan tahu segera dalam huruf merah cerah

0:16:50.090,0:16:53.033
Jika tidak bertemu dengan harapan bahwa

0:16:53.033,0:16:56.005
OK, saya sedang kembali pada konvensional debugging sisi:

0:16:56.005,0:16:58.090
Aku keluar big guns: saya mengeluarkan Ruby debugger

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

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

0:17:04.085,0:17:06.002
Jadi aku harus mengatur hal itu

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

0:17:07.063,0:17:08.065
Tidak!

0:17:08.065,0:17:10.087
Aku * bisa * Sebaliknya-jika aku akan melakukan itu tetap-

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

0:17:13.000,0:17:16.045
untuk mengontrol jalur kode, membuatnya pergi cara yang saya inginkan

0:17:16.045,0:17:19.013
Dan sekarang, "Ok, pasti aku sudah fixed it!

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

0:17:22.012,0:17:24.022
Dan, tentu saja, 9 kali dari 10, Anda tidak memperbaikinya

0:17:24.022,0:17:26.072
atau Anda jenis sebagian tetap itu tetapi Anda tidak benar-benar memperbaikinya

0:17:26.072,0:17:30.040
dan sekarang saya harus melakukan semua hal-hal manual lagi

0:17:30.040,0:17:32.086
* atau * saya sudah memiliki sekelompok tes

0:17:32.086,0:17:34.031
dan jalankan saya dapat hanya kembali mereka secara otomatis

0:17:34.031,0:17:35.056
dan aku bisa, jika beberapa dari mereka gagal

0:17:35.056,0:17:36.087
"Oh, aku tidak memperbaiki semuanya

0:17:36.087,0:17:38.040
Tidak masalah, saya akan hanya pergi kembali!"

0:17:38.040,0:17:39.096
Jadi, intinya adalah bahwa

0:17:39.096,0:17:41.095
kau tahu, Anda * bisa * melakukannya di sisi kiri

0:17:41.095,0:17:45.004
tapi Anda menggunakan teknik yang sama dalam kedua kasus

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

0:17:48.062,0:17:50.004
membosankan dan rawan kesalahan

0:17:50.004,0:17:51.078
Jika Anda melakukan sedikit lebih banyak pekerjaan

0:17:51.078,0:17:53.095
tapi Anda dapat membuatnya otomatis dan berulang

0:17:53.095,0:17:55.071
dan, Anda tahu, beberapa keyakinan tinggi

0:17:55.071,0:17:57.003
bahwa Anda mengubah hal-hal dalam kode Anda

0:17:57.003,0:17:58.092
Anda tidak melanggar hal-hal yang digunakan untuk bekerja

0:17:58.092,0:18:00.091
dan pada dasarnya lebih produktif

0:18:00.091,0:18:02.047
Jadi kalian semua sama hal-hal

0:18:02.047,0:18:04.037
tetapi dengan, misalnya, "delta" ekstra bekerja

0:18:04.037,0:18:07.086
Anda menggunakan usaha Anda di banyak leverage yang lebih tinggi

0:18:07.086,0:18:10.036
Jadi itu sebabnya jenis pandangan saya terhadap TDD adalah hal yang baik

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

0:18:11.088,0:18:15.011
Ini hanya memerlukan [Anda] refactor keterampilan yang ada

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

0:18:18.014,0:18:19.034
Ketika saya mulai melakukan hal ini rasanya

0:18:19.034,0:18:21.049
"Ok, saya akan mengajar kursus di rel

0:18:21.049,0:18:22.065
Aku benar-benar harus fokus pada pengujian

0:18:22.065,0:18:24.032
Jadi aku kembali ke beberapa kode yang telah kutulis

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

0:18:26.087,0:18:29.006
dan aku mulai mencoba menulis tes untuk itu

0:18:29.006,0:18:31.019
dan itu * begitu menyakitkan *

0:18:31.019,0:18:33.033
karena kode tidak ditulis dalam cara yang dapat diuji

0:18:33.033,0:18:34.097
Ada semua jenis interaksi

0:18:34.097,0:18:36.038
Ada, seperti, bersarang conditional

0:18:36.038,0:18:38.083
Dan jika Anda ingin memisahkan pernyataan tertentu

0:18:38.083,0:18:41.070
dan tes-tes memicu-hanya pernyataan itu

0:18:41.070,0:18:44.000
jumlah hal-hal yang Anda harus mengatur dalam pengujian Anda

0:18:44.000,0:18:45.009
telah terjadi-

0:18:45.009,0:18:46.040
Ingat ketika berbicara tentang pura-pura kereta kecelakaan-

0:18:46.040,0:18:48.014
Anda harus mengatur semua infrastruktur ini

0:18:48.014,0:18:49.063
hanya untuk mendapatkan * satu * baris kode

0:18:49.063,0:18:51.015
dan Anda melakukan itu dan Anda pergi

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

0:18:52.074,0:18:54.034
Aku menulis 20 baris setup

0:18:54.034,0:18:56.059
supaya aku dapat menguji dua baris dalam fungsi saya!"

0:18:56.059,0:18:58.085
Apa yang benar-benar memberitahu Anda-seperti sekarang menyadari —

0:18:58.085,0:19:00.042
adalah fungsi Anda * buruk *

0:19:00.042,0:19:01.049
Itu adalah fungsi sangat ditulis

0:19:01.049,0:19:02.052
Hal ini tidak dapat diuji fungsi

0:19:02.052,0:19:03.088
It's got terlalu banyak bagian yang bergerak

0:19:03.088,0:19:06.026
dependensi yang * dapat Jadilah rusak

0:19:06.026,0:19:07.070
Ada tidak ada jahitan di fungsi saya

0:19:07.070,0:19:11.008
yang memungkinkan saya untuk menguji secara individual perilaku yang berbeda

0:19:11.008,0:19:12.083
Dan sekali Anda mulai melakukan tes pertama pembangunan

0:19:12.083,0:19:15.043
karena Anda harus menulis tes Anda dalam potongan kecil

0:19:15.043,0:19:17.053
itu agak membuat masalah berlalu

0:19:17.053,9:59:59.000
Sehingga telah pencerahan