() translation by (you can also view the original English article)
Ide inti dari Test-Driven Development (TDD) adalah menulis tes sebelum menulis kode fungsional, dan kemudian menulis hanya jumlah yang paling sedikit dari kode yang diperlukan untuk membuat tes lulus. Ini mungkin terdengar aneh untuk dikembangkan dengan cara ini, tetapi sebenarnya sangat berguna, karena basis pengujian berfungsi ganda sebagai spesifikasi parsial dari kode utama.
Namun, mengingat premis sederhana semacam itu, ada sejumlah terminologi dan teknik yang luar biasa. Dalam artikel ini, saya mengumpulkan istilah dan kata kunci paling penting yang mungkin Anda dengar, dan mendefinisikannya.
Referensi Terminologi
Ujian Penerimaan
Test-first programming diperbolehkan untuk tes fungsional tingkat tinggi.
Lihat pengujian tingkat tertinggi memvalidasi bahwa pengujian Penerimaan umumnya dijalankan di lingkungan sebagai pengujian fungsional dan pengujian sistem.
Tuntutan
Asersi adalah pernyataan yang melakukan pemeriksaan aktual pada output perangkat lunak.Secara umum, fungsi tunggal yang disebut assert
cukup untuk mengekspresikan pemeriksaan apa pun. Dalam prakteknya, perpustakaan tes sering memiliki banyak fungsi untuk memenuhi kebutuhan spesifik (seperti assertFalse
, assertEqual
dan banyak lagi) untuk menawarkan analisis yang lebih baik dan output yang lebih ramah.
Behavior Testing
Sebuah teknik pengujian yang menggabungkan uji ganda ke perangkat lunak, menegaskan bahwa itu memanggil metode yang benar dalam urutan yang benar. Lihat tiruan untuk contoh. Juga lihat pengujiannya.
Perilaku-Driven Development (BDD)
Sebuah bagian dari TDD didorong oleh komunikasi yang lebih jelas dan dokumentasi yang tepat, BDD mungkin merupakan perkembangan TDD yang paling baru.
Gagasan intinya adalah untuk menggantikan terminologi membingungkan dan pengembang-sentris (tes, suite, pernyataan dll) dengan bahasa di mana-mana bahwa semua pemangku kepentingan yang berpartisipasi (termasuk staf non-teknis, dan, mungkin, klien) dapat mengerti.
Lihat cerita pengguna.
Pengujian Black-Box
Prinsip umum dalam pengujian di mana orang yang menulis tes tidak tahu atau menghindari internal perangkat lunak, memilih untuk menguji antarmuka publik dari perangkat lunak secara ketat oleh antarmuka atau spesifikasinya. Lihat pengujian kotak putih.
Pengujian Nilai Batas
Sebuah strategi untuk menulis tes untuk menangkap satu kesalahan dan jenis kesalahan serupa lainnya. Untuk melakukan pengujian batas nilai, ujilah input di sekitar batas-batas tertentu yang mungkin bermasalah. Dalam kasus bilangan bulat, ini mungkin 0
, -1
, MIN_INT
, MAX_INT
dan nilai-nilai serupa lainnya.
Dummy
Asersi adalah pernyataan yang melakukan pemeriksaan aktual pada output software.
Dummy adalah jenis uji ganda yang tidak pernah digunakan oleh perangkat lunak yang sebenarnya, tetapi hanya digunakan dalam pengujian untuk mengisi parameter yang diperlukan.
Fake
Fakes adalah uji ganda yang mengimplementasikan fungsionalitas yang diperlukan dengan cara yang berguna dalam pengujian, tetapi juga secara efektif mendiskualifikasinya dari yang digunakan dalam lingkungan produksi. Sebagai contoh, basis data nilai-kunci yang menyimpan semua nilai dalam memori dan kehilangan mereka setelah setiap eksekusi berpotensi memungkinkan pengujian berjalan lebih cepat, tetapi kecenderungannya untuk menghancurkan data tidak akan memungkinkannya untuk digunakan dalam produksi.
Fixture
Lingkungan tertentu yang harus disiapkan sebelum tes dapat dijalankan. Ini umumnya terdiri dari pengaturan semua tes ganda dan dependensi lainnya untuk software yang diuji: seperti memasukkan data yang telah ditetapkan ke dalam database fake, mengatur struktur direktori tertentu dalam sistem file palsu, mengatur properti pada ketergantungan software yang diuji.
Functional Testing
Aktivitas pengujian tingkat tinggi yang memverifikasi bahwa semua persyaratan bisnis produk terpenuhi. Pengujian fungsional umumnya melibatkan penggunaan cerita pengguna untuk fokus pada tingkat persyaratan yang lebih tinggi untuk mencakup sebanyak mungkin skenario penggunaan. Lihat pengujian penerimaan dan pengujian sistem. Sebagai contoh:
1 |
# In this example we check that the about page of the website is working as expected
|
2 |
open 'example.com'
|
3 |
clickOn 'about us'
|
4 |
assertThereIs 'We are a small Example company'
|
Green
Sebuah colloquialism untuk koleksi lulus tes, atau kadang-kadang tes kelulusan tertentu. Lihat merah.
Tes integrasi
Kegiatan pengujian tingkat menengah yang memverifikasi satu set modul tertentu bekerja dengan benar bersama-sama. Tes integrasi seperti tes unit tanpa menggunakan uji ganda untuk subset dependensi tertentu, pada dasarnya menguji interaksi antara software dependensinya. Contoh:
1 |
# In this example we check that the newly registered user,
|
2 |
# who was referred by another user, gets an on-site "friendship" created.
|
3 |
# Here we check the interaction between the form controller,
|
4 |
# database, and a User active record
|
5 |
db = new Fake Db
|
6 |
u1 = db.createUser(name='john') |
7 |
RegistrationForm(db, name='kate', referred='john').save() |
8 |
assert(u1.hasFriend('kate')) |
Mock
Jenis test double yang dibuat untuk test atau test case tertentu. Ini diharapkan untuk disebut beberapa kali dan memberikan jawaban yang telah ditentukan. Pada akhir tes, tiruan menimbulkan kesalahan jika tidak dipanggil sebanyak yang diharapkan. Sebuah tiruan dengan harapan yang ketat adalah bagian dari framework assertion. Contoh:
1 |
# In this example we use a mock database to check that the form
|
2 |
# uses the database to store the new user.
|
3 |
# If the database has not been called at the end of the test,
|
4 |
# the mock itself will raise an assertion error.
|
5 |
db = new Mock Db
|
6 |
db.expect('save').once().with(name='john') |
7 |
RegistrationForm(db, name='john').save() |
Monkey-Patching
Cara untuk memperluas dan mengubah perilaku objek dan kelas yang ada dalam bahasa pemrograman. Monyet-patch dapat digunakan sebagai alternatif untuk injeksi ketergantungan dan uji ganda dengan langsung memodifikasi fungsi yang ada yang disebut oleh perangkat lunak yang diuji (dan mengubahnya kembali setelah tes).
1 |
# In this example we replace the standard library function
|
2 |
# to prevent the test from using a real filesystem
|
3 |
filesystem.listdir = f (name) -> ['.', '..', 'foo', 'bar']; |
4 |
assertEqual(MyFileSearch('foo').count(), 1) |
Red
Sebuah colloquialism untuk koleksi tes gagal atau kadang-kadang tes gagal tertentu. Lihat hijau.
Refactoring
Proses peningkatan rincian implementasi kode tanpa mengubah fungsinya.
Refactoring tanpa tes adalah proses yang sangat rapuh, karena pengembang melakukan refactoring tidak pernah bisa memastikan bahwa perbaikannya tidak melanggar beberapa bagian fungsionalitas.
Jika kode ditulis menggunakan pengembangan berbasis tes, pengembang dapat memastikan bahwa refactoring-nya berhasil segera setelah semua tes lulus, karena semua fungsionalitas yang diperlukan dari kode tersebut masih benar.
Regression
Cacat software yang muncul dalam fitur tertentu setelah beberapa kejadian (biasanya perubahan dalam kode).
Pengujian Skenario
Lihat pengujian fungsional.
Setup
Proses mempersiapkan fixture. Lihat teardown. Contoh:
1 |
# In this example we prepare a fake database with some fake values
|
2 |
# that we will need across multiple tests
|
3 |
db = new Fake Db
|
4 |
db.createUser(name='john') |
5 |
db.createUser(name='kate') |
6 |
db.createFriendship('john', 'kate') |
Pengujian State
Suatu bentuk pengujian unit ketika kode pengujian memberikan pengujian berfungsi ganda dan menegaskan bahwa status ganda ini telah dimodifikasi dengan cara yang benar. Lihat pengujian perilaku.
1 |
# In this example, like in an example on mock objects,
|
2 |
# we will check that the form uses the database to store the new user.
|
3 |
# This time we will check state, instead of behavior
|
4 |
db = new Fake Db
|
5 |
RegistrationForm(db, name='john').save() |
6 |
assertInList('john', db.listUsers()) |
Stub
Fakes adalah tes ganda yang pernah digunakan oleh software sebenarnya.
Jenis tes ganda yang dapat membalas perangkat lunak yang diuji dengan jawaban yang telah ditentukan. Tidak seperti tiruan, bagaimanapun, bertopik biasanya tidak memeriksa apakah mereka telah dipanggil dengan benar, melainkan hanya memastikan bahwa software dapat memanggil dependensinya.
System Testing
Aktivitas pengujian tingkat tinggi ketika keseluruhan perangkat lunak diuji dari atas ke bawah. Ini termasuk pengujian fungsional, serta memeriksa karakteristik lain (seperti kinerja dan stabilitas).
SUT
Singkatan untuk software di bawah ujian. Digunakan untuk membedakan perangkat lunak di bawah tes dari dependensi.
Teardown
Proses membersihkan fixture. Dalam bahasa sampah yang dikumpulkan, fungsi ini kebanyakan ditangani secara otomatis. Lihat pengaturan.
Test
Periksa mungkin terkecil kebenaran. Sebagai contoh, sebuah tes untuk formulir web bisa cek bahwa, ketika diberikan sebuah alamat email tidak valid, bentuk memperingatkan pengguna dan menyarankan perbaikan. Lihat kasus uji.
Test Case
Kumpulan tes dikelompokkan berdasarkan atribut. Misalnya, kasus uji untuk formulir web dapat koleksi tes memeriksa perilaku formulir untuk input yang valid dan tidak valid yang berbeda.
1 |
function t1:
|
2 |
assertNoError(
|
3 |
RegistrationForm(name='john', password='horse battery staple correct').save() |
4 |
)
|
5 |
|
6 |
function t2:
|
7 |
assertError(MissingPassword, RegistrationForm(name='john').save()) |
8 |
|
9 |
function t3:
|
10 |
assertError(StupidPassword, RegistrationForm(name='john', password='password').save()) |
Test Coverage
Cerita pengguna biasanya didefinisikan dalam bahasa manusia untuk fokus pada pengalaman pengguna.
Setiap jenis metrik yang mencoba untuk memperkirakan kemungkinan perilaku penting SUT masih belum dicakup oleh tes. Teknik yang paling populer termasuk berbagai jenis cakupan kode: teknik yang memastikan bahwa semua pernyataan kode yang mungkin (atau fungsi, atau cabang logis dalam kode) telah dieksekusi selama pengujian.
Test Cycle
Sebuah proses pengembangan TDD. Mengingat bahwa pengembangan TDD dimulai dengan menulis beberapa tes, jelas bahwa rangkaian uji mulai berwarna merah. Segera setelah pengembang menerapkan semua fungsi yang baru diuji, tes berubah menjadi hijau. Sekarang pengembang dapat dengan aman mem-refactor implementasinya tanpa risiko memperkenalkan bug baru, karena ia memiliki test suite untuk diandalkan. Setelah refactoring selesai, pengembang dapat memulai siklus lagi dengan menulis tes untuk lebih banyak fungsi baru. Dengan demikian, tes merah-hijau-refactor siklus.
Test Double
Uji ganda adalah objek yang dibuat oleh kode uji dan diteruskan ke SUT untuk menggantikan dependensi nyata. Sebagai contoh, tes unit harus sangat cepat dan hanya menguji perangkat lunak tertentu.
Untuk alasan ini, dependensinya, seperti database atau perpustakaan sistem file interaksi, biasanya digantikan oleh objek yang bertindak dalam memori daripada berbicara dengan database atau sistem file nyata.
Ada empat kategori utama dari tes ganda: dummies, fakes, stubs, dan mocks.
Test Suite
Kumpulan kasus uji yang menguji sebagian besar perangkat lunak. Sebagai alternatif, semua uji kasus untuk perangkat lunak tertentu.
Test-First Programming
Pengujian white-box memungkinkan analisis lebih mendalam tentang kemungkinan masalah dalam kode.
Test-first programming adalah istilah yang sedikit lebih luas untuk pengembangan berbasis tes. Sementara TDD mempromosikan kopling ketat antara tes menulis (biasanya tes unit) dan menulis kode, pemrograman tes-pertama memungkinkan untuk tes fungsional tingkat tinggi sebagai gantinya. Namun, perbedaan dalam penggunaan umum jarang dicatat, dan dua istilah biasanya digunakan secara bergantian.
Unit Testing
Teknik pengujian tingkat terendah yang terdiri dari uji kasus untuk sekecil mungkin kode. Sebuah tes unit tunggal biasanya memeriksa hanya perilaku kecil tertentu, dan kasus uji unit biasanya mencakup semua fungsi dari satu fungsi atau kelas tertentu.
User Story
Satu deskripsi dari sekelompok orang tertentu yang bersedia melakukan tugas tertentu menggunakan SUT untuk mencapai tujuan tertentu. Kisah-kisah pengguna biasanya didefinisikan dalam bahasa manusia, menggunakan istilah sederhana, terpusat pada pengguna untuk menghindari mempertimbangkan rincian penerapan dan untuk fokus pada pengalaman pengguna. Sebagai contoh:
1 |
As a user, I want to be able to find my friends on this website by my address book, instead of looking for them one by one, because that will save me a lot of time.
|
White-Box Testing
Testing white-box adalah teknik pengujian ketika seseorang yang melakukan pengujian mengetahui tentang, atau dapat membaca, internal dari SUT. Tidak seperti pengujian black-box yang lebih umum, testing white-box memungkinkan analisis lebih mendalam tentang kemungkinan masalah dalam kode.
Misalnya, nilai batas tertentu mungkin tidak terlihat hanya berdasarkan spesifikasi software, tetapi mungkin terlihat jelas dari penerapannya.
Selain itu, teknik uji cakupan biasanya, menurut definisi, merupakan bagian dari pengujian kotak putih.