Siapa yang melakukan pengembangan berbasis tes?

23

Saya telah bekerja di ruang perusahaan selama 4 ½ tahun terakhir dan telah memperhatikan bahwa secara umum, perusahaan bukanlah lingkungan yang kondusif untuk gaya pengembangan pertama yang diuji. Proyek biasanya dengan biaya tetap, garis waktu tetap dan gaya air terjun. Pengujian unit apa pun, jika dilakukan sama sekali, biasanya dilakukan setelah pengembangan dalam fase QA dan dilakukan oleh tim lain.

Sebelum bekerja untuk suatu perusahaan, saya berkonsultasi dengan banyak perusahaan kecil hingga menengah, dan tidak ada dari mereka yang mau membayar untuk proyek uji coba gaya pengembangan yang pertama. Mereka biasanya ingin pengembangan dimulai segera, atau setelah tugas desain pendek: yaitu, sesuatu yang lebih mirip dengan Agile, meskipun beberapa klien ingin semuanya dipetakan mirip dengan air terjun.

Dengan jenis toko, perusahaan, dan klien apa yang paling berhasil dalam pengembangan berbasis tes? Jenis proyek apa yang cenderung kondusif untuk TDD?

Edward J. Stembler
sumber
5
"tidak ada dari mereka yang mau membayar untuk proyek pengembangan gaya uji-pertama" - katakan apa? Total waktu yang diperlukan untuk mengimplementasikan metode di kelas, menurut pengalaman saya, jauh lebih sedikit jika Anda menulis "tes" terlebih dahulu. Namun, belakangan ini, Anda tidak akan menemukannya disebut sebagai pengembangan uji-pertama atau pengembangan yang didorong oleh tes, karena itu cara yang agak tidak merata dalam memandangnya. Anda dapat menganggap unit-tes dalam TDD sebagai deskripsi terprogram kode Anda, yang kemudian dipenuhi selama "perbaikan tes". Tentunya lebih baik memiliki gagasan tentang apa yang ingin Anda lakukan sebelum melakukannya? :)
bzlm
2
@ bzlm dua situasi di mana tes "pembayaran" pertama valid. Di mana pengguna mengharapkan banyak prototipe dengan pengerjaan ulang besar-besaran di setiap langkah karena mereka tidak yakin apa hasil terbaik dan di mana biaya untuk mendapatkan pengembang untuk mensimulasikan perilaku eksternal dengan cukup benar untuk memiliki tes yang valid adalah hal yang mahal. Keduanya tidak selalu merupakan tempat yang menyenangkan, tetapi keduanya dapat menjadi hal yang umum dalam perusahaan.
Bill
6
Dua asumsi cacat: pertama, bahwa TDD lebih mahal. Agile lebih murah daripada air terjun karena Anda tidak menghabiskan waktu membangun hal yang salah dan TDD lebih murah daripada tes terakhir karena Anda tidak menghabiskan waktu membangun hal-hal yang tidak berfungsi. Kedua, TDD itu tidak berarti Anda dapat "segera memulai pengembangan". Dengan TDD, Anda mulai mengembangkan segera. TDD tidak berarti bahwa Anda menulis semua tes Anda terlebih dahulu. Itu berarti Anda menulis tes tunggal terlebih dahulu. Tidak seorang pun ingin melakukan TDD seperti yang Anda pahami, termasuk pengguna TDD.
Rein Henrichs
@Rein: amin, saudara !!
IAbstract
Tidakkah pertanyaan ini mendorong gaya daftar menjawab tanpa kriteria nyata kapan jawaban itu dijawab "dengan benar"? Bukankah pertanyaan-pertanyaan semacam ini dianggap tidak cocok untuk format Tanya Jawab StackExchange karena kita berakhir dengan 16+ jawaban, yang masing-masing menjawab pertanyaan namun tidak ada yang memenuhi kriteria keluar yang tidak ada untuk "benar"?
Nathan C. Tresch

Jawaban:

33

Setiap baris kode yang saya tulis menggunakan pengembangan yang digerakkan oleh tes. Jika manajemen tidak ada di papan tulis dengan tes menulis pertama maka saya tidak memberi tahu manajemen tentang hal itu. Saya merasa bahwa pengembangan yang digerakkan oleh tes adalah proses yang lebih baik.

mpenrow
sumber
19
Saya tidak memilih Anda secara khusus karena Anda melakukan TDD, tetapi karena Anda melakukan apa yang Anda anggap benar tanpa meminta izin. Itulah yang dilakukan para profesional.
Sergio Acosta
24
@Sergio - itu definisi mengerikan tentang apa yang dilakukan seorang profesional. Berpikir bahwa sesuatu itu benar tidak selalu membuatnya demikian, khususnya dalam masalah teknik. Ada waktu dan tempat untuk kadang-kadang melanggar aturan untuk menyelesaikan sesuatu, tetapi mengatakan bahwa tanda profesional adalah melakukan apa yang dianggap benar tanpa meminta izin (khususnya ketika Anda dibayar untuk melakukan proses tertentu), itu adalah penyederhanaan berlebihan dari subjek yang kompleks.
luis.espinal
6
Jangan menganggap apa yang saya katakan sebagai definisi profesional. Dan jangan berharap komentar dua kalimat menjadi perlakuan mendalam dari subjek yang kompleks. Maaf.
Sergio Acosta
22
Bagaimana dengan ini: "seorang profesional melakukan hal yang benar tanpa harus disuruh melakukannya". Lebih baik? Itu yang saya maksud.
Sergio Acosta
3
@CraigTp - Ada satu bab penuh dalam buku Peopleware: Proyek dan Tim Produktif yang menyinggung "Metodologi" yang mengatakan bahwa ia membunuh motivasi dan memadamkan api batin yang dapat dimiliki seseorang jika "Metodologi" terlalu ketat karena ia menghilangkan kebebasan individu mengandaikan bahwa mereka akan membuat pilihan yang buruk secara sistematis. Lingkungan kerja yang baik adalah lingkungan di mana individu dapat membuat keputusan yang ia nilai terbaik untuk "kebaikan yang lebih besar", jika gagal maka sesuaikan, tetapi sebaliknya, biarkan individu menjadi pusat keputusan, bukan "Metodologi"
JF Dion
17

Bos saya memberi saya makan yang baik hari ini, saya pikir saya akan mencurinya seperti mencuri dari orang lain.

"Apakah kamu mengharapkan tukang kayu mengukur papan sebelum dia memotongnya?"

Saya mengambil kelas toko kayu di sekolah menengah dan mengerjakan konstruksi sampai sekolah. Mantra kami selalu "ukur dua kali, potong sekali" yang ditindaklanjuti dengan sarkastik, "Aku memotongnya dan memotongnya lagi dan itu masih terlalu pendek!"

MIA
sumber
Saya tidak bisa mengatakan bahwa saya setuju dengan analogi itu. Itu tidak benar-benar mendekati kompleksitas dalam pembangunan. Tapi sekali lagi, saya tidak sepenuhnya percaya pada TDD.
xil3
@ xil3 Ya, analoginya tidak bagus. Itu akan lebih "mengukur sekitar, tidak memeriksa setelah, dan kemudian memotong". Tetapi jawabannya masih sangat bagus
BЈовић
12

Jika Anda menguji setelahnya, Anda membuat pengerjaan ulang karena kode yang akan Anda tulis akan sulit untuk diuji. Ketika Anda menguji pertama, atau bahkan menguji-sedikit-di-tengah-tetapi-sebelum-Anda-komit perangkat lunak yang Anda buat akan lebih mudah untuk diuji. Perusahaan yang membuat pengujian unit setelah kode produksi ditulis untuk memenuhi daftar periksa adalah usaha yang sia-sia.

Integrasi dengan perangkat lunak sulit yang ada untuk menguji juga akan menciptakan upaya tambahan, karena Anda harus membuat lapisan uji untuk dapat mengontrol dependensi yang dikonsumsi oleh kode uji baru Anda yang mengkilap. Dalam beberapa kasus, seperti dengan kerangka kerja yang banyak menggunakan negara global dan objek dewa ini bisa sangat sulit untuk dicapai. Kesulitan yang dirasakan dari pengembangan yang digerakkan oleh tes seringkali adalah kombinasi dari pengalaman kurang dengan penulisan tes yang baik dan mencoba untuk menguji kode yang digabungkan secara ketat.

Anda dapat menguji kode drive bahkan dalam proyek air terjun, itu adalah disiplin teknik bukan teknik manajemen proyek.

Saya bukan penggemar TDD dengan cara apa pun, tetapi mengajarkan Anda banyak hal tentang desain perangkat lunak.

Ryan Roberts
sumber
1
"Jika Anda menguji setelahnya, Anda membuat pengerjaan ulang karena kode yang akan Anda tulis akan sulit untuk diuji." Itu tidak benar. Itu hanya akan menjadi kenyataan jika Anda tidak membuat kode yang longgar. Apakah Anda yakin Anda tidak bisa menulis kode diuji tanpa pengujian terlebih dahulu?
melahap elysium
@devoured elysium: Saya setuju: menulis tes pertama bukan satu-satunya cara untuk menulis kode yang dapat diuji.
Giorgio
6

Bersabarlah dengan saya, karena ini akan memiliki rasa bersih .Net: p

Berkenaan dengan jenis-jenis proyek yang dapat menerima pendekatan uji-pertama, beberapa hal yang saya perhatikan:

  • apakah Anda berurusan dengan basis kode yang ada? Seringkali sangat mahal untuk melakukan retrofit tempat test suite. Dapatkan gagasan tentang berapa banyak utang teknis yang diwariskan di sana
  • platform dan kerangka kerja tertentu secara inheren tidak tahan uji. Pengalaman terkini yang menyita pikiran saya - SharePoint, misalnya sangat sulit (tapi bukan tidak mungkin) untuk TDD. Untuk hal-hal seperti ini, Anda mungkin harus menggunakan produk isolator komersial seperti TypeMock dapat membantu.
  • pendekatan implementasi tertentu cocok untuk TDD daripada yang lain. Misalnya, ASP.Net dengan kode-belakang - tidak begitu bisa diuji. ASP.Net MVC - dapat diuji. Silverlight dengan kode-belakang - tidak bisa diuji. Silverlight dengan MVVM - dapat diuji.

Pada akhirnya, sementara "organisasi" dapat melakukan banyak hal untuk mendukung langkah untuk menguji terlebih dahulu, perubahan kunci yang perlu terjadi adalah dalam benak pengembang. Saya sudah menyerah pada pendekatan "engkau harus menulis tesmu terlebih dahulu" dan bukannya mencari saat-saat yang bisa diajar.

Beri +1 pada komentar mpenrow tentang tidak memberi tahu mgmt jika mereka memiliki masalah: p

HY
sumber
1
Kata baik. Masalah besar muncul ketika ada sejumlah besar hutang teknis karena pada saat itu Anda bahkan tidak dapat mulai mengimplementasikan pengujian, dan Anda tidak dapat menulis ulang aplikasi untuk menghilangkan hutang teknis, dan kadang-kadang Anda bahkan tidak dapat memperbaiki hutang teknis karena Anda memiliki begitu banyak fitur tambahan yang ditugaskan untuk diselesaikan.
Wayne Molina
6

Situasi Anda tidak akan berubah dengan cepat, dan kunci untuk melewatinya adalah menjadikannya bagian dari disiplin pribadi Anda, dan menjadi ahli dalam hal itu, sebelum mencoba mendorongnya pada orang lain. Jika Anda dapat menjadi contohnya, maka manajer Anda akan melihat manfaat obyektif.

Anda juga dapat membuat kasus bisnis yang baik:

  • TDD dapat diringkas secara sederhana sebagai "spek yang sistem dapat secara otomatis memverifikasi dirinya terhadap". Ini bukan pemrograman yang berbeda, itu tidak membangun produk yang berbeda.

  • Pengujian unit benar-benar hanya bentuk pengujian otomatis; yang hanya membiarkan komputer melakukan sendiri apa yang kemungkinan dilakukan perusahaan membayar insinyur ruang-daging secara manual. Tes otomatis berjalan lebih cepat, lebih konsisten, dan - saat ditulis dengan baik - memberikan umpan balik dan deskripsi serta arahan yang cepat, ringkas dan akurat untuk masalah ini

  • TDD, ketika dilakukan oleh seseorang yang tahu apa yang mereka lakukan, menghasilkan hasil secepat kode-pertama. Akan ada kurva pembelajaran / pelatihan (dan, jika insinyur Anda berasal dari kelompok pendek talenta maka ini sepenuhnya dapat membunuh peluang Anda untuk mendorong TDD - dalam hal ini yang terbaik yang dapat Anda lakukan adalah terus memperjuangkannya dan buat pertanyaan manajemen mereka daripada TDD)

  • TDD sangat banyak tentang memikirkan tugas yang ada sebelum memulai. Ini sepanjang garis "ukur dua kali, potong sekali" - pengukuran ekstra menambah jumlah waktu marginal untuk tugas, tetapi menghindari membuang sumber daya Anda yang paling berharga - jam dev).

... dan ingat saja; hal terpenting yang dapat Anda lakukan adalah memimpin dengan memberi contoh. Jika Anda kasar dalam TDD, investasikan beberapa jam ekstra untuk menjadi lebih baik. Setelah Anda mahir, mulailah melakukannya di tempat kerja (akankah manajer Anda benar-benar mengeluh bahwa Anda menulis tes?). Bertarung satu per satu dan lakukan langkah-langkah ke arahnya - pergi untuk seluruh shebang kemungkinan akan menghasilkan kegagalan dan kesalahan akan menimpamu jika Anda mendorongnya dengan keras.

STW
sumber
2

Saya lakukan. Ini adalah cara pengembangan pilihan saya, dan saya bekerja untuk perusahaan keuangan besar yang senang bagi saya untuk bekerja dengan cara yang saya inginkan selama saya memenuhi tenggat waktu dan menghasilkan kode kualitas. Dilakukan dengan benar, uji pengembangan pertama tidak perlu lebih lama dari uji setelah pengembangan dan jangan lupa hasil lainnya dari uji pengembangan pertama cacat kurang dari pengujian sistem nanti.

Chris Knight
sumber
2

Kunci untuk melakukan TDD adalah hanya melakukannya sebagai bagian dari penulisan kode Anda, dan jika perlu, Anda tidak memberi tahu siapa pun bahwa Anda melakukannya. Tidak perlu menjelaskan semua yang Anda lakukan. Hasil akhir Anda adalah kode yang berfungsi.

Jika Anda menjelaskan "Saya sedang menulis tes," maka The Powers That Be dapat mengatakan "Oh, kita bisa menghilangkan itu!" Tetapi jika Anda tidak memberi tahu siapa pun, maka Anda masih memiliki tes sebagai residu dari proses pengkodean.

Pemrograman lebih dari mengetik pernyataan kerja ke dalam editor. Jika orang tidak bisa mengatasinya, maka lindungi mereka dari kebenaran ini sampai mereka siap menanganinya. "Siap menanganinya" dalam hal ini berarti ketika Anda memiliki satu atau dua proyek yang sudah selesai, selesai tepat waktu dengan kode yang kuat dan dapat diandalkan, dan oh ya, lihat, Anda juga memiliki unit test untuk itu.

Andy Lester
sumber
Misalkan Anda menerapkan modul tertentu dan, setelah menulis unit test dan mengimplementasikan kelas dan metode yang sesuai, Anda melihat bahwa desain Anda cacat dan Anda harus membuang beberapa kelas (dan unit test yang sesuai)? Tidakkah ini menghemat waktu untuk mulai menulis unit test ketika desain sedikit stabil, yaitu ketika Anda telah menerapkan cukup kelas untuk modul itu sehingga struktur keseluruhan menjadi cukup jelas?
Giorgio
2

Sedih untuk mengatakan, saya belum mendapatkan kesempatan untuk menggunakannya dalam arti tes pertama yang benar-benar klasik sendiri, jadi saya tidak bisa mengatakan "saya! Saya! Saya melakukannya!". Saya berasumsi bahwa pertanyaannya adalah menanyakan "industri / perusahaan apa yang menggunakan TDD secara keseluruhan" daripada "bisakah ada yang menyelinap TDD ke dalam kehidupan sehari-hari mereka?". Saya setuju bahwa seorang pengembang dapat benar-benar melakukan TDD tanpa memaksa seluruh kelompok untuk melakukannya, saya hanya tidak berpikir itu adalah inti dari pertanyaan.

Kesan saya dari mendengarkan di sekitar industri adalah bahwa Anda lebih cenderung melihat TDD di sebagian besar grup pengembangan di perusahaan dalam situasi di mana:

  • Tidak ada basis kode besar yang ada sebelum dimulainya TDD

  • Perusahaan ini tidak besar dan karena itu tidak memiliki banyak pushback "kami selalu melakukannya dengan cara lain".

  • Perusahaan tidak melakukan pembelian besar-besaran untuk proses formalisasi. Itu bukan untuk mengatakan bahwa Anda tidak dapat menerapkan TDD di, misalnya, perusahaan bersertifikat CMMI - tetapi jika Anda memiliki proses yang tidak TDD, mendapatkan semua proses yang Anda pantau dengan pemutakhiran CMMI dapat menjadi investasi besar.

  • Tes dapat dituliskan - ini adalah basis kode yang paling kompleks, karena bahkan jika Anda tidak dapat dengan mudah skrip lapisan terdekat dengan pengguna, Anda dapat membuat skrip beberapa internal. Tapi saya melihat situasi dengan opsi yang dikembangkan dengan baik untuk otomatisasi pengujian sebagai tempat termanis untuk TDD, karena didasarkan pada rerunning dan tidak merusak seluruh baterai tes di mana Anda memerlukan umpan balik pada pengujian dengan sangat cepat. Pemikiran saya adalah bahwa aplikasi web mandiri adalah target TDD yang baik, sistem dengan integrasi COTS utama atau input yang bukan berbasis GUI mungkin rumit.

  • Sistem dalam keadaan non-prototipe. Idealnya versi besar berikutnya setelah prototipe - di mana bukti konsep selesai dan proyek didanai, tetapi semua orang tahu bahwa upaya selanjutnya harus melompat dalam kualitas.

  • Stakeholder yang diinvestasikan dalam proses.

bethlakshmi
sumber
2
+1 untuk poin pertama saja; untuk melakukan TDD dengan benar, Anda tidak dapat melakukan basis kode yang besar dan diinvestasikan tanpa TDD (atau pengujian secara umum). Jika ya, Anda kemungkinan tidak akan pernah bisa menambahkannya karena Anda harus memilih A) Perkuat seluruh aplikasi untuk mendukung pengujian, karena kemungkinan besar itu tidak ditulis dengan abstraksi yang tepat untuk pengujian unit, atau B) Tulis ulang semuanya dari awal dan gunakan TDD dari awal.
Wayne Molina
2

Saya sudah mencoba di mana mungkin - tetapi saya pikir itu benar-benar turun ke lingkungan perusahaan di mana Anda menemukan diri Anda. Saya bekerja di industri game selama bertahun-tahun (sebagai artis btw), dan tidak ada konsep TDD - hanya pendekatan QA brute force. Saya pindah ke pengembangan web, dan belum bekerja di agensi dengan pengakuan formal (atau pengetahuan ...) unit testing / TDD. Hal yang sama berlaku untuk sebagian besar rekan saya di industri, yang bekerja di berbagai disiplin ilmu.

Dalam agensi yang berfokus pada penjualan, TDD menawarkan sangat sedikit ROI jangka pendek kepada pelanggan, sehingga sulit untuk menjual kepada manajer lini ketika melakukan scoping proyek. Namun, semakin besar proyek yang didapat, semakin meyakinkan proyek itu.

Mengingat bahwa buku-buku seperti Death March menunjuk ke sebuah fenomena yang lazim, yaitu sebuah industri yang diganggu oleh pembangunan yang digerakkan oleh "crunch" dan "tonggak sejarah" - saya bertaruh bahwa TDD mungkin langka di luar startup yang didanai dengan baik atau toko-toko perusahaan monolitik. Bukannya orang-orang di sana tidak percaya pada nilai TDD - tetapi terlalu abstrak untuk dijual kepada pelanggan mereka.

sunwukung
sumber
2

Saya mencoba masuk ke TDD sendiri. Saya pikir selama Anda mengikuti rute yang Anda sudah tahu (pekerjaan sehari-hari) itu agak sederhana. Tapi saya tidak bisa membungkus kepala saya di sekitar tes untuk bagian-bagian UI atau ketika Anda harus datang dengan solusi baru untuk beberapa masalah yang belum pernah Anda temui sebelumnya. Atau menggunakan kerangka kerja yang Anda tidak tahu.

Jadi saya kira Anda harus melakukan semacam LearningTests, pisahkan bukti konsep dan menulis ulang sesudahnya, dll. Atau apakah saya salah?

Dan (saya tahu ini sudah lama tapi saya belum melihat jawaban yang bagus): bagaimana Anda membuat kode algoritma menggunakan TDD (ketika hasilnya mungkin rumit untuk benar-benar "Menegaskan" dengan mudah)?

Saya benar-benar dapat melihat sisi positif dari TDD dan im di atas kapal tetapi sangat sulit bagi pemula ketika kode yang Anda tulis membawa Anda paling banyak dua kali lipat waktu (dan Anda punya rekan yang tidak melihat pro sama sekali dan mengejek Anda dengan RAD)

Carsten
sumber
1

Saya mencoba beberapa kali dan itu berhasil. Sayangnya sebagian besar waktu jika saya bisa menguji aplikasi saya secara manual, saya menunda tes unit sampai saya merasa terlalu bosan untuk mengimplementasikan sesuatu yang lain atau ada bug yang tidak dapat saya perbaiki dengan mudah.

Alexandru
sumber
Keuntungan datang kemudian, karena Anda pada dasarnya mendokumentasikan perilaku sebagai kode. Setiap perubahan kode harus tetap lulus tes atau perilaku telah berubah.
1

Saya lakukan itu. Kemajuan kisah pengguna kami dilacak di papan Kanban, yang memiliki "Punya Tes?" kolom di sebelah kiri (hulu) Pembangunan.

Tata letak yang agak tidak biasa ini membuat satu kebijakan eksplisit: tes penerimaan otomatis gagal (biasanya, beberapa dari mereka) harus ada. Itu harus dapat dilacak ke kebutuhan pelanggan. Tes penerimaan muncul dari kondisi kepuasan , yang dihasilkan dari percakapan yang dimulai dengan kartu cerita . Saya memfasilitasi lokakarya reguler di mana kami melakukan brainstorming persyaratan, mengidentifikasi kesenjangan, dan mencari tahu tes penerimaan utama yang memastikan nilai pengguna diberikan ketika mereka lulus ( definisi selesai ). Ini adalah aktivitas kolaboratif yang melibatkan programmer, analis bisnis, dan terkadang penguji.

Putaran umpan balik pengujian penerimaan agak panjang: mungkin perlu beberapa hari untuk menyelesaikan cerita. Pengembangan memiliki loop umpan balik TDD sendiri yang lebih pendek.

"[... tidak ada tes-gaya pertama ...] Lebih mirip dengan Agile ...."

Ini adalah salah tafsir Agile. Definisi selesai adalah komponen utama Agile dan salah satu pilar yang menjadi sandarannya adalah pengujian penerimaan otomatis (apa yang saya jelaskan di atas adalah salah satu cara untuk melakukannya.) Jika pemrograman ekstrim (XP) digunakan sebagai metode implementasi Agile, maka ATDD / BDD dan TDD ditentukan.

azheglov
sumber
1

Saya lakukan, tetapi umumnya hanya untuk komponen non-ui, dan ketika saya tahu saya tidak dapat menyimpan seluruh algoritma untuk modul di kepala saya pada satu waktu, atau ketika modul adalah bagian baru dari sistem apa pun yang saya kerjakan, jadi saya tidak bisa mengandalkan sebagian besar perpustakaan yang saya gunakan untuk memiliki debugged yang tinggi.

Pada dasarnya, saya lakukan ketika kompleksitas persyaratan berarti saya bisa tersesat dalam kode.

Ini adalah kebiasaan yang sulit untuk memulai, dan memang memerlukan dukungan manajemen, tetapi, ketika tes Anda mulai setengah jalan melalui pengembangan, itu bisa menjadi penyelamat hidup!

John
sumber
1

Saya ingin mengajukan pertanyaan ini, untuk melihat berapa banyak perusahaan yang benar-benar mempraktikkan TDD.

Dalam 11 tahun saya telah memprogram secara profesional hanya dua organisasi terakhir yang bahkan menyadari TDD (yang terbentang hampir 5 tahun, sebelum waktu itu TDD tidak sepopuler sekarang). Saya akan memotong untuk mengejar dan menjawab pertanyaan Anda sebelum menyimpang ke penjualan saya untuk TDD :)

Di perusahaan terakhir tempat saya bekerja (penerbit akademis online untuk koleksi humaniora dan sains), kami tahu kami perlu berlatih TDD tetapi kami tidak pernah berhasil. Dalam pembelaan kami, kami memiliki basis kode 250k, jadi menambahkan tes ke basis kode yang tidak dapat diuji ukurannya terasa tidak dapat diatasi (saya merasa bersalah mengetik itu sekarang!). Bahkan yang terbaik dari kita membuat kesalahan .

Siapa pun yang telah melakukan bahkan sejumlah kecil TDD tahu betapa menyakitkannya pengujian retrofit pada kode brown field yang tidak dapat diuji dapat menjadi ... Penyebab utama adalah dependensi implisit (Anda tidak dapat menarik semua tuas untuk menegaskan hasil dari kode - Anda tidak dapat mengejek skenario) dan pelanggaran prinsip tanggung jawab tunggal (tes rumit, dibuat-buat, membutuhkan terlalu banyak pengaturan dan sulit dipahami ).

Kami sementara meningkatkan tim QA kami (dari satu, mungkin dua orang menjadi setengah lusin atau lebih) untuk menguji platform sebelum rilis. Itu adalah waktu yang sangat mahal dan secara finansial bijaksana, beberapa rilis akan memakan waktu tiga bulan untuk menyelesaikan 'pengujian'. Bahkan pada saat itu kami tahu kami menghadapi masalah, mereka bukan 'pemblokir' atau 'kritis', hanya 'prioritas tinggi'.

Jika Anda memiliki pengalaman komersial selama bertahun-tahun, Anda akan menghargai bahwa setiap perusahaan menegaskan tugas - tugas penting , dan kemudian menciptakan tingkat prioritas yang lebih tinggi di atas itu, dan kemungkinan besar satu di atas itu juga - terutama ketika seseorang dari atas mendorong perbaikan fitur / bug. Saya ngelantur ...

Saya senang melaporkan saya sedang berlatih TDD di perusahaan saya saat ini (telekomunikasi, web, dan rumah pengembangan aplikasi seluler), ditambah dengan Jenkins CI untuk memberikan laporan analisis statis lainnya (cakupan kode menjadi yang paling berguna setelah menegaskan test suite lulus) . Proyek tempat saya menggunakan TDD adalah sistem pembayaran dan sistem komputasi grid.

Promosi penjualan ...

Ini seringkali bisa menjadi perjuangan berat yang membenarkan pengujian otomatis untuk anggota tim non-teknis. Tes menulis memang menambah lebih banyak pekerjaan pada proses pengembangan tetapi ... saat Anda berinvestasi dalam pengujian sekarang, Anda akan menghemat dalam upaya pemeliharaan nanti. Anda benar-benar hanya meminjam waktu . Semakin lama produk digunakan, semakin besar penghematan yang akan Anda buat - dan itu akan membantu Anda menghindari penulisan ulang yang besar .

Tes pertama berarti Anda mengkode niat Anda terlebih dahulu, dan kemudian mengonfirmasi kode Anda memenuhi niat itu. Ini memberikan fokus dan menyaring kode Anda untuk hanya melakukan apa yang dimaksudkan dan tidak lebih (baca tanpa mengasapi). Ini adalah spesifikasi dan dokumentasi yang dapat dieksekusi pada saat yang sama (jika tes Anda ditulis dengan baik, dan tes harus dapat dibaca / bersih seperti kode sistem Anda, jika tidak lebih!).

Non-programmer tidak akan (sering) tidak memiliki wawasan ini sehingga TDD tidak memiliki banyak nilai untuk mereka, dan dianggap sebagai jalan pintas sekali pakai ke tanggal rilis sebelumnya.

Pemrograman adalah domain kami , dan menurut saya ini menjadikannya tanggung jawab kami , sebagai profesional, untuk memberi saran tentang praktik terbaik seperti TDD. Bukan untuk manajer proyek untuk memutuskan apakah itu dilakukan untuk mengurangi waktu pengembangan, itu di luar yurisdiksi mereka . Dengan cara yang sama mereka tidak memberi tahu Anda apa kerangka kerja, solusi caching atau algoritma pencarian untuk digunakan, mereka seharusnya tidak memberi tahu Anda jika Anda harus menggunakan pengujian otomatis.

Menurut pendapat saya industri pengembangan perangkat lunak (secara keseluruhan) rusak saat ini, fakta bahwa memiliki tes untuk perangkat lunak Anda BUKAN norma.

Bayangkan ini di industri lain: medis, penerbangan, mobil, kosmetik, mainan lunak, minuman beralkohol dll. Saya meminta tunangan saya untuk menyebutkan sebuah industri di mana mereka tidak menguji produk dan dia tidak bisa!

Mungkin tidak adil untuk mengatakan tidak ada pengujian yang terjadi karena ... tetapi di perusahaan tanpa pengujian otomatis, prosesnya sangat manual / manusiawi (baca kikuk dan sering rawan kesalahan).

Satu hal yang saya akan pertanyakan dalam pertanyaan Anda ...

Mereka biasanya ingin pengembangan dimulai segera, atau setelah bertugas desain pendek. Lebih mirip dengan Agile.

Menjadi "Agile" tidak meresepkan proses tanpa tes, anggota pertama yang terdaftar di agilemanifesto.org adalah Kent Beck , pencipta XP dan TDD!

Dua buku yang saya sangat sarankan jika Anda tertarik pada TDD, atau hanya belum membacanya dan merupakan programmer yang tertarik (semua orang membaca ini kan?;)

Tumbuh Perangkat Lunak Berorientasi Objek Dipandu oleh Tes

Kode Bersih - Robert C Martin ("Paman Bob") Seri

Dua buku ini saling melengkapi satu sama lain dan memadatkan banyak arti menjadi beberapa halaman.

Terima kasih telah mengajukan pertanyaan ini :)

Greg K
sumber
0

Mereka yang mengimplementasikan klon. Saya tidak bisa memikirkan proses yang lebih baik ketika Anda mengembangkan sesuatu, yang bekerja persis seperti program yang ada.

P Shved
sumber
Hal yang sama berlaku untuk prototyping / eksplorasi. Alih-alih meretasnya sampai terlihat benar, Anda mendefinisikan apa yang "terlihat benar" artinya. (Ini tidak berlaku ketika Anda membutuhkan manusia untuk mengatakan "kelihatannya benar".) Dan kemudian Anda meretas sampai Anda mendapatkan bilah hijau.
Frank Shearar
0

Jelas ini adalah kasus yang sangat tidak biasa, tetapi para pengembang SQLite menggunakan tes secara luas. (Saya menganggap proses pengembangan mereka adalah ujian pertama, meskipun saya tidak yakin.)

  • 73.000 baris kode
  • 91.378.600 baris kode uji

Lihat http://www.sqlite.org/testing.html

Paul D. Waite
sumber