YA tegas dengan TDD (dan dengan beberapa pengecualian)
Baik kontroversial, tapi saya berpendapat bahwa siapa pun yang menjawab 'tidak' untuk pertanyaan ini kehilangan konsep dasar TDD.
Bagi saya, jawabannya adalah ya jika Anda mengikuti TDD. Jika tidak maka tidak ada jawaban yang masuk akal.
DDD dalam TDD
TDD sering dikutip memiliki manfaat utama bagimu.
- Pertahanan
- Memastikan kode dapat berubah tetapi tidak perilakunya .
- Ini memungkinkan praktik refactoring yang sangat penting .
- Anda mendapatkan TDD ini atau tidak.
- Desain
- Anda menentukan apa yang harus dilakukan sesuatu, bagaimana seharusnya berperilaku sebelum menerapkannya .
- Ini sering berarti keputusan implementasi yang lebih terinformasi .
- Dokumentasi
- Test suite harus berfungsi sebagai dokumentasi spesifikasi (persyaratan).
- Menggunakan tes untuk tujuan seperti itu berarti bahwa dokumentasi dan implementasi selalu dalam keadaan konsisten - perubahan ke satu berarti perubahan ke yang lain. Bandingkan dengan menjaga persyaratan dan desain pada dokumen kata yang terpisah.
Pisahkan tanggung jawab dari implementasi
Sebagai programmer, sangat menggoda untuk menganggap atribut sebagai sesuatu yang penting dan getter dan setter sebagai semacam overhead.
Tetapi atribut adalah detail implementasi, sementara setter dan getter adalah antarmuka kontrak yang benar-benar membuat program bekerja.
Jauh lebih penting untuk mengeja bahwa objek harus:
Izinkan kliennya mengubah kondisinya
dan
Izinkan kliennya menanyakan kuasanya
lalu bagaimana keadaan ini sebenarnya disimpan (yang atributnya paling umum, tetapi bukan satu-satunya cara).
Tes seperti
(The Painter class) should store the provided colour
Penting untuk bagian dokumentasi TDD.
Fakta bahwa implementasi akhirnya adalah sepele (atribut) dan tidak membawa manfaat pertahanan seharusnya tidak diketahui oleh Anda ketika Anda menulis tes.
Kurangnya rekayasa bolak-balik ...
Salah satu masalah utama dalam dunia pengembangan sistem adalah tidak adanya round-trip engineering 1 - proses pengembangan suatu sistem terpecah menjadi sub-proses yang terpotong-potong, yang artefak-artefaknya (dokumentasi, kode) sering tidak konsisten.
1 Brodie, Michael L. "John Mylopoulos: menjahit benih pemodelan konseptual." Pemodelan Konseptual: Yayasan dan Aplikasi. Springer Berlin Heidelberg, 2009. 1-9.
... dan bagaimana TDD memecahkannya
Ini adalah bagian dokumentasi TDD yang memastikan bahwa spesifikasi sistem dan kodenya selalu konsisten.
Desain dulu, implementasikan nanti
Dalam TDD kami menulis tes penerimaan gagal pertama, baru kemudian menulis kode yang membiarkan mereka lulus.
Di dalam BDD tingkat yang lebih tinggi, kita menulis skenario terlebih dahulu, lalu membuatnya lewat.
Mengapa Anda harus mengecualikan setter dan pengambil?
Secara teori, sangat mungkin dalam TDD untuk satu orang untuk menulis tes, dan yang lain untuk mengimplementasikan kode yang membuatnya lulus.
Jadi tanyakan pada diri sendiri:
Haruskah orang yang menulis tes untuk kelas menyebutkan getter dan setter.
Karena getter dan setter adalah antarmuka publik ke kelas, jawabannya jelas ya , atau tidak akan ada cara untuk mengatur atau menanyakan keadaan suatu objek.
Jelas, jika Anda menulis kode terlebih dahulu, jawabannya mungkin tidak begitu jelas.
Pengecualian
Ada beberapa pengecualian yang jelas untuk aturan ini - fungsi yang jelas detail implementasi dan jelas bukan bagian dari desain sistem.
Misalnya, metode lokal 'B ()':
function A() {
// B() will be called here
function B() {
...
}
}
Atau fungsi pribadi di square()sini:
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
Atau fungsi lain yang bukan bagian dari publicantarmuka yang perlu ejaan dalam desain komponen sistem.