Apa peran Arsitek Perangkat Lunak dalam proses Pengembangan Tes-Didorong?

Seperti yang saya pahami, Test-Driven Development adalah tentang menulis tes untuk menentukan spesifikasi program (Anda dapat memperbaiki saya jika saya salah).

Jika ada seseorang yang bertanggung jawab untuk menulis spesifikasi (termasuk API publik) untuk perangkat lunak (sebut saja Arsitek Perangkat Lunak), apakah itu berarti Arsitek Perangkat Lunak harus menulis semua tes?

Atau apakah Arsitek Perangkat Lunak menulis spesifikasi, dan kemudian menyerahkannya kepada pengembang untuk menulis pengujian?

Atau apakah Anda membiarkan spesifikasi tumbuh secara organik dengan mengizinkan semua pengembang untuk menulis tes mereka sendiri, dan lupa memiliki Arsitek Perangkat Lunak?

architecture tdd

— Robert Harvey
sumber

Ada beberapa perdebatan tentang english.se tentang apa yang Anda maksud dengan "tumbuh secara organik" - english.stackexchange.com/questions/17853/… - apakah Anda ingin mengonfirmasi :)

— JoseK

@Jose: Kalimat terakhir dalam OP saya dimaksudkan untuk sedikit meributkan, karena tampak jelas bagi saya bahwa suatu program harus selalu memiliki spesifikasi terperinci dari seorang pelanggan. Tetapi pelanggan tidak selalu tahu persis apa yang mereka inginkan, itulah sebabnya proses pengembangan perangkat lunak berulang ada. Lihat di sini untuk informasi lebih lanjut tentang metafora "perangkat lunak yang berkembang".

— Robert Harvey

Jawaban:

Pengembangan Test-Driven adalah tentang menulis tes untuk menentukan spesifikasi program

Anda tidak menulis tes untuk menentukan spesifikasi, deskripsi tes, cerita pengguna, dan deskripsi fitur adalah spesifikasi, dalam arti 'pohon mati'.

Untuk meninjau, proses TDD secara singkat adalah:

mendefinisikan proyek dalam hal fitur
menggambarkan pemangku kepentingan, perilaku, dan tujuan setiap fitur menggunakan cerita pengguna
tentukan givens yang diharapkan, peristiwa / kondisi pemicu, dan perilaku / hasil yang terkait dengan cerita pengguna menggunakan deskripsi tes [dan ini melengkapi 'spesifikasi']
pilih satu set fitur untuk setiap iterasi; iterasi harus pendek [saya menghilangkan langkah-langkah perencanaan dan estimasi untuk singkatnya]
- kode tes untuk fitur (itu akan gagal, tetapi Anda harus membuat keputusan API untuk kode tes)
- cukup menerapkan fitur sehingga tes lulus
- refactor kode jika perlu
- ulangi dengan tes berikutnya sampai fitur selesai
- ulangi dengan fitur berikutnya sampai iterasi selesai
ulangi dengan iterasi berikutnya sampai proyek selesai

berapa banyak desain, arsitektur, dokumentasi pendukung, dan lain-lain yang Anda pilih bukan bagian dari TDD. Ada beberapa 'praktik terbaik' praktis yang dapat Anda baca, tetapi perlu diingat bahwa itu adalah praktik 'terbaik' di bengkel orang lain , bukan milik Anda.

perhatikan bahwa intinya adalah bagi pelanggan dan pengembang untuk datang dengan fitur dan menulis cerita dan deskripsi pengujian bersama , untuk saling pengertian

jadi, dengan itu, pertanyaan aslinya adalah:

apa peran seorang arsitek perangkat lunak dalam TDD?

Dan jawaban singkatnya adalah:

Sama seperti dulu, sama seperti dulu. - David Byrne

EDIT: Jawaban panjangnya adalah: arsitek memainkan peran visioner / penyelidik / pengiritasi / pendukung / backstop yang biasa selama seluruh proses, sebagaimana diperlukan.

EDIT 2: maaf saya melewatkan inti dari sub-pertanyaan! Setiap orang bertanggung jawab untuk menulis spesifikasi; semua pengembang termasuk arsiteknya jika diperlukan ditambah pelanggan . Pengembang juga membuat kode tes.

— Steven A. Lowe
sumber

Itu masuk akal, tetapi satu-satunya langkah yang pernah saya dengar orang bicarakan dalam konteks TDD adalah lima langkah dalam lima peluru Anda (menggambarkan proses refactor merah-hijau). Apakah peluru yang tersisa benar-benar bagian dari TDD yang tepat, atau apakah mereka bagian dari beberapa metodologi yang lebih luas seperti Agile atau DDD?

— Robert Harvey

@ Robert hmmm ... pertanyaan bagus! secara teknis peluru lainnya adalah XP; Saya belajar XP dan TDD pada saat yang sama dan tidak pernah terpikir untuk memisahkan mereka. Sampai sekarang ;-)

— Steven A. Lowe

@ Robert melakukan beberapa bacaan penyegaran; lihat suntingan (FYI menggunakan XP ref extremeeprogramming.org dan TDD ref agiledata.org/essays/tdd.html#WhatIsTDD )

— Steven A. Lowe

Hmm, tautan yang Anda berikan untuk TDD mengatakan bahwa TDD benar-benar Desain yang Didorong oleh Tes . Sekarang saya kembali ke tempat saya mulai. "Anda mendesain secara organik, dengan kode yang berjalan memberikan umpan balik di antara keputusan."

— Robert Harvey

@Robert suntingan tentu membantu saya untuk memahami pertanyaan dengan lebih baik. Saya mengambil D sebagai Pengembangan dan menafsirkannya sebagai seluruh siklus hidup, bukan hanya bagian pengkodean. TDDev adalah cara yang baik untuk mempelajari keterampilan arsitektur - refactoring memiliki kecenderungan untuk mendorong satu ke arah itu

— Steven A. Lowe

Arsitek Perangkat Lunak tidak menulis semua tes. Itu akan menempatkan terlalu banyak ke pundak satu orang ke pikiran saya.

Arsitek Perangkat Lunak harus dapat membuat sketsa formulir awal untuk API yang kemudian dikembangkan oleh para pengembang tes untuk itu dan kemudian membangun API. Namun, Arsitek Perangkat Lunak mungkin memiliki berbagai standar kode yang belum tentu dapat diuji, misalnya dokumentasi atau konvensi penamaan. Ada juga potensi untuk API awal akan kehilangan beberapa panggilan yang sebagai implementasi dilakukan panggilan baru ditambahkan ke API. Dengan demikian, akan ada beberapa pertumbuhan organik ke API sebagai basis kode tumbuh tetapi peran Arsitek adalah dalam memberikan pedoman tingkat tinggi dan berusaha untuk memastikan mereka diikuti.

Tentu saja ada kasus-kasus di mana sebuah tim dapat memutuskan untuk tidak memiliki Arsitek Perangkat Lunak tetapi tergantung pada skala API dan perusahaan yang terlibat ini mungkin atau mungkin bukan ide yang baik.

— JB King
sumber