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?
sumber
Jawaban:
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.
sumber
Bos saya memberi saya makan yang baik hari ini, saya pikir saya akan mencurinya seperti mencuri dari orang lain.
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!"
sumber
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.
sumber
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:
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
sumber
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.
sumber
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.
sumber
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.
sumber
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.
sumber
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.
sumber
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)
sumber
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.
sumber
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.
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.
sumber
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!
sumber
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 ...
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 :)
sumber
Mereka yang mengimplementasikan klon. Saya tidak bisa memikirkan proses yang lebih baik ketika Anda mengembangkan sesuatu, yang bekerja persis seperti program yang ada.
sumber
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.)
Lihat http://www.sqlite.org/testing.html
sumber