Apakah TDD layak dalam proyek-proyek open source kolaboratif

Katakanlah saya ingin memulai proyek sumber terbuka yang saya harap / harapkan memiliki banyak orang mengirimkan tambalan dan yang lainnya. Apakah layak untuk mengambil pendekatan TDD yang ketat? Bisakah / haruskah saya berharap / percaya kolaborator untuk menulis tes kualitas setiap kali mereka mengirimkan tambalan?

Satu hal yang saya pikirkan adalah menulis suite pengujian untuk laporan bug individual dan permintaan fitur dan mengharuskan semua tambalan / permintaan tarik membuat tes lulus, tetapi pada saat itu sepertinya akan lebih baik hanya menulis fitur / perbaikan bug diri.

Sejauh yang saya tahu, sebagian besar proyek open source utama yang menggunakan TDD (atau setidaknya menulis tes) tampaknya sebagian besar ditulis murni oleh individu atau tim, di mana mudah untuk menegakkan praktik seperti TDD.

open-source tdd collaboration

— DormoTheNord
sumber

Berbagi penelitian Anda membantu semua orang. Beri tahu kami apa yang telah Anda coba dan mengapa itu tidak memenuhi kebutuhan Anda. Ini menunjukkan bahwa Anda telah meluangkan waktu untuk mencoba membantu diri sendiri, itu menyelamatkan kami dari mengulangi jawaban yang jelas, dan yang paling utama itu membantu Anda mendapatkan jawaban yang lebih spesifik dan relevan. Lihat juga Cara Meminta

— nyamuk

@gnat Saya sudah mencari di StackExchange, dan ada beberapa pertanyaan di mana orang bertanya tentang contoh proyek open source dengan unit test, yang tidak sama dengan pertanyaan saya. Sesuai permintaan Anda, saya telah menambahkan beberapa informasi lebih lanjut.

— DormoTheNord

DormoTheNord Saya percaya @gnat berarti spesifik, contoh yang dikutip .

— haneefmubarak

"Akan lebih baik hanya menulis fitur / perbaikan bug sendiri." Dengan atau tanpa tes? Apakah Anda seorang pendukung TDD atau hanya memeriksa untuk melihat apakah itu layak dalam konteks ini?

— JeffO

Tentu saja Anda dapat / seharusnya mengharapkan kolaborator untuk menulis tes kualitas setiap kali mereka mengirimkan tambalan. Itu tidak hanya menguntungkan - ini sangat umum di proyek open source besar hari ini (saya bisa memberikan contoh jika Anda mau).

— Benjamin Gruenbaum

Jawaban:

Anda tidak dapat benar-benar menerapkan pendekatan TDD (tes pertama) pada proyek sumber terbuka di mana tambalan dapat diajukan oleh masyarakat umum.

Apa yang dapat Anda terapkan adalah bahwa semua tambalan harus memiliki satu set uji kasus untuk perbaikan yang disertakan dalam tambalan dan bahwa uji kasus tersebut, serta semua kasus uji yang ada, harus lulus. Anda dapat menegakkan ini dengan hanya memberikan hak komitmen kepada beberapa pengembang tepercaya yang diketahui menggunakan dan menyetujui kebijakan proyek dan dengan menyatakan secara terbuka bahwa pengiriman / permintaan tarik hanya akan dimasukkan jika mereka datang dengan melewati kasus uji (dengan cakupan yang memadai).

Ini tidak memastikan bahwa tes ditulis terlebih dahulu , tetapi memastikan bahwa tes itu ditulis .

— Bart van Ingen Schenau
sumber

Tentunya pemilik repositori dapat menolak untuk melakukan perubahan apa pun yang tidak sesuai dengan standar kualitas proyek? Mungkin kualitas dan kuantitas kontribusi akan berkurang jika kontributor tidak menyukai ini, tetapi itu tidak berarti Anda tidak dapat menegakkannya. Pasti?

— Tom W

@ Tom: Bagaimana Anda memeriksa bahwa kiriman saya dibuat sesuai dengan praktik TDD dan tidak, misalnya, dengan tes yang ditulis setelah implementasi dilakukan?

— Bart van Ingen Schenau

Ah, aku mengerti maksudmu. Saya kira beberapa kehilangan ketelitian tidak bisa dihindari, tetapi Anda masih dapat memverifikasi bahwa kode dilengkapi dengan tes, bahwa tes cukup granular dan mereka mencakup semua yang seharusnya. Saya tidak begitu akrab dengan git, tetapi untuk permintaan tarik yang diberikan, apakah mungkin untuk memeriksa urutan komit untuk perubahan tersebut untuk melihat bahwa pengembang mengikuti proses yang sesuai untuk memproduksinya?

— Tom W

Dengan kata lain, Anda tidak dapat mengkonfirmasi proses internal seseorang, tetapi Anda dapat memastikan output yang memenuhi standar tertentu. Memerlukan tes, dan memastikan desain logis dalam kekuatan pemilik.

— Adrian Schneider

Anda dapat meminta orang-orang untuk mengirimkan tambalan hanya tes sebelum diizinkan untuk mengerjakan kode; ini akan memberikan kesempatan tambahan untuk meninjau desain yang direncanakan sebelum kode itu sendiri ditulis.

Dalam praktiknya, ini dapat membunuh antusiasme apa pun yang dimiliki orang untuk berkontribusi pada proyek - atau mungkin menyalakan api pada mereka yang setuju dengan metodologi Anda.

Namun, para pengulas harus sangat baik tentang membalikkan ulasan desain dengan cepat, agar tidak menghentikan pengembangan.

— Alex Feinman
sumber