Pengembangan Lintas Bahasa Berbasis Tes

9

Pertanyaan singkat: Bagaimana Anda mengikuti Pengembangan Test-Driven pada proyek yang mencakup beberapa bahasa?

Secara khusus, saya menulis aplikasi web yang menggunakan JavaScript dan PHP, dan saya ingin mengikuti prinsip-prinsip TDD, tapi saya tidak yakin bagaimana mengintegrasikannya. Apakah saya menjalankan suite pengujian terpisah untuk bagian JS dan PHP, dan menggunakan mengejek di suite JS untuk meniru respons server? Apakah ada teknik untuk pengujian unit kedua komponen dalam satu kali?

Ini adalah pengalaman pertama saya menggunakan Test-Driven Development, jadi saran apa pun yang dapat Anda bagikan tentang cara membuatnya tidak terlalu menakutkan akan sangat bagus. Alasan saya memilihnya adalah begitu saya selesai membuat prototipe, persyaratan berubah, memaksa saya untuk mengubah desain saya. Saya pikir jika saya memulai dari awal, saya ingin menulis lebih banyak kode yang dapat diperluas dengan pengujian regresi bawaan sejak awal.

Saya menulis tes PHP saya di SimpleTest dan tes JavaScript saya di JsTestDriver. Saya sudah terbiasa dengan paradigma berorientasi objek, jadi saya punya beberapa kelas di PHP, dan saya melakukan sesuatu yang serupa dalam JavaScript menggunakan pewarisan prototypal. Saya juga mulai membaca buku ini tentang TDD dengan Python dan yang ini tentang TDD dalam JavaScript , tetapi dari semua yang saya lihat, ini tidak menggambarkan pengujian aplikasi secara penuh (di luar menggunakan sesuatu seperti Selenium atau driver web lain) untuk melakukan pengujian penerimaan front-end. Apakah TDD tidak cocok untuk pengembang penuh-tumpukan?

— Chris Olsen
sumber

1

Kecuali Anda dipaksa untuk menggunakan SimpleTest, saya akan merekomendasikan beralih ke PHPUnit. SimpleTest tampaknya tidak terlalu aktif dan sedikit tertinggal dalam hal mengejek dan cakupan kode.

— Cerad

9

Apakah ada teknik untuk pengujian unit kedua komponen dalam satu kali?

Itu sebenarnya akan menjadi kebalikan dari pengujian unit - pengujian unit, terutama dalam gaya TDD, berarti menguji komponen Anda secara terpisah . Jadi jawabannya adalah ya, "jalankan suite tes terpisah untuk bagian JS dan PHP ", jika tidak ini bukan pengujian unit dan bukan TDD.

Tentu saja, tes integrasi otomatis dapat menguji "kedua komponen dalam satu proses", dan Anda dapat memanfaatkan alat yang sudah Anda sebutkan (seperti Selenium). Tapi itu biasanya tes yang lebih kompleks, dikembangkan di luar siklus TDD.

— Doc Brown
sumber

3

Yang penting adalah membedakan antara TDD dan ATDD . AT di sana adalah singkatan dari " tes penerimaan ", dan ini mengacu pada pengembangan di mana Anda pertama kali memulai dengan tes penerimaan, yang kemungkinan akan menguji seluruh tumpukan. Ini juga kadang-kadang disebut "pengembangan didorong oleh tes luar". Ketika orang berbicara tentang TDD, "T" di sana mungkin merujuk secara khusus untuk unit test.

Bagian penting dari pengujian unit adalah mengisolasi unit yang sedang diuji dari ketergantungannya. Ini memberi Anda dua manfaat yang sangat penting:

Anda dapat membuat tes Anda sangat cepat, sehingga Anda dapat menjalankannya sangat sering sebagai bagian dari siklus umpan balik yang sangat singkat. Daripada menjalankannya, katakanlah, setiap jam, Anda harus dapat menjalankan semua tes unit Anda setelah setiap perubahan kecil, sehingga Anda langsung mendapatkan umpan balik mereka tentang apakah perubahan itu menghancurkan sesuatu.
Tes Anda dapat ditargetkan sekaligus dengan perilaku yang sangat spesifik. Jika salah satu dari mereka gagal, Anda harus dapat menentukan secara instan sifat bug yang ditunjukkan oleh tes.

Karena pentingnya isolasi ini, Anda akan secara otomatis ingin tes dibatasi pada unit yang jauh lebih kecil daripada batas bahasa Anda memaksa Anda. Meskipun ini bukan aturan yang keras dan cepat, Anda sering berharap satu kelas menjadi unit yang dapat diuji. Jadi dalam hal TDD, masalah bahasa kurang lebih relevan.

Jika, di sisi lain, Anda ingin melakukan ATDD, pastikan Anda melihat sumber daya untuk ini secara khusus (ini sering dilakukan sebagai bagian dari BDD, jadi lihat juga alat yang ditargetkan pada itu). Di sinilah sesuatu seperti Selenium secara alami cocok. Biasanya, ketika melakukan ATDD Anda masih menulis tes unit, dan pada kenyataannya untuk lulus setiap tes penerimaan Anda mungkin menguji drive implementasinya dengan tes unit juga. Jadi, bahkan jika Anda ingin melakukan ATDD, memahami cara menulis unit test masih penting.

— Ben Aaronson
sumber

Keren, saya belum pernah melihat ATDD tapi saya kenal dengan Behat dan Behave untuk BDD. Saya menghargai umpan baliknya. Masih mencoba membungkus kepala saya di sekitar mentalitas tes mikro TDD :)

— Chris Olsen

@ChrisOlsen Ada dua aspek yang perlu diperhatikan: tes unit (vs integrasi atau penerimaan) dan ketika Anda menulisnya (sebelum kode produksi, bukan setelahnya). Jika keduanya tampak seperti mentalitas aneh, Anda bisa mencoba memahami yang pertama sebelum yang kedua. Banyak orang tidak berlatih TDD tetapi masih bersikeras pada cakupan unit test yang sangat menyeluruh.

— Ben Aaronson

1

Anda juga tidak harus menggunakan TDD untuk setumpuk penuh aplikasi. TDD sebagai metodologi pengembangan lebih cocok untuk bagian logika aplikasi. Bagian-bagian yang memerlukan sentuhan yang lebih eksperimental, seperti kata desain frontend, interaksi pasti, atau domain database lebih baik dilakukan dalam gaya tradisional karena Anda belum tahu apakah itu akan menjadi versi final.

Tetapi logika aplikasi tidak boleh berubah di masa depan, dan jika itu terjadi Anda menghadapi creep persyaratan yang sangat ditakuti. Itu membuatnya sempurna untuk serangkaian uji regresi untuk memberikan kepercayaan diri setiap kali melakukan perubahan pada kode, yang merupakan tujuan akhir TDD.

Paman Bob menjelaskan cara ini lebih baik daripada saya. https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html

— cllamach
sumber