Kapan saya harus menulis tes integrasi?


30

Menurut aturan tes unit TDD ditulis sebelum kode produksi, tetapi bagaimana dengan tes Integrasi yang melakukan interaksi antara benda kabel beton (bukan tiruan)?

Haruskah mereka ditulis sebelum unit test atau setelah kode produksi hanya untuk menguji "perkabelan"?

Perhatikan bahwa saya tidak berbicara tentang Penerimaan atau tes fungsional tetapi tes integrasi tingkat bawah.

Jawaban:


49

Buku Rspec , di antara sumber daya BDD lainnya, menyarankan siklus seperti ini:

masukkan deskripsi gambar di sini

Intinya, prosesnya adalah:

While behaviour required
    Write an integration test for a specific behaviour
    While integration test failing
        Write a unit test to fulfil partial behavior
        While unit test failing
            Write code to make unit test pass
        Commit
        While refactoring can be done
            Refactor
            While unit test failing
                Write code to make unit test pass
            Commit
    Push

Penafian: Tidak ada keraguan dalam pikiran saya bahwa ini mengarah pada kode dan produk terbaik, tetapi itu bisa memakan waktu. Ada segala macam kesulitan di sekitar data dan determinisme, ketika harus mengatakan bahwa tes integrasi harus selalu lulus. Ini tidak sesuai dalam semua situasi; terkadang Anda hanya perlu mengeluarkan barang dari pintu.

Yang mengatakan, memiliki proses yang ideal dalam pikiran itu bagus. Ini memberi Anda titik untuk berkompromi.


2
Terima kasih @ pdr tapi saya menentukan bahwa saya tidak berbicara tentang tes Penerimaan yang ditulis sebelum / pada awal iterasi, saya tertarik pada tes integrasi tingkat rendah.
Chedy2149

@ chedy2149: Akkh. Ketinggalan komentar itu. Sebelum saya menghapus jawaban saya, saya pikir Anda harus lebih spesifik tentang apa yang Anda maksud dengan "level bawah" dalam konteks tes integrasi.
pdr

Tingkat lebih rendah: perilaku mana yang tidak ditentukan oleh pengguna atau klien dan yang digunakan untuk menguji interaksi kelas / komponen yang diharapkan oleh pengembang.
Chedy2149

4
Sebenarnya, saya tidak berpikir itu membuat perbedaan jika Anda memasukkan "tes penerimaan" atau "tes integrasi" dalam gambar itu - ini adalah pandangan ideal untuk segala jenis tes pada tingkat abstraksi yang berbeda. Tapi IMHO masalah sebenarnya adalah bukan bahwa ini mungkin "memakan waktu" - masalah sebenarnya adalah bahwa menulis tes integrasi "sebelumnya" terhadap antarmuka publik yang masih beeing dirancang dengan bantuan TDD seperti menembak pada "target bergerak" ".
Doc Brown

@DocBrown jadi jawaban Anda adalah setelah kode produksi dan sebelum rilis?
Chedy2149

10

Proyek nyata menunjukkan kepada saya bahwa tidak mungkin untuk menulis tes unit dan kemudian integrasi dan bahkan arah yang berlawanan salah :-) Jadi, saya biasanya menulis tes unit bersama dengan yang integrasi.

Mengapa? Biarkan saya menulis bagaimana saya melihat kedua jenis tes:

  1. Tes unit - Selain Wikipedia dan semua informasi yang diketahui, tes unit membantu Anda mempersempit desain Anda , meningkatkan model, relasi. Alurnya sederhana: begitu Anda mulai mengetik proyek baru / komponen baru, sebagian besar waktu Anda membuat semacam PoC . Ketika Anda selesai, Anda selalu memiliki metode panjang, kelas panjang, metode dan kelas yang tidak koheren, dll.

    Tes unit membantu Anda untuk menghapus masalah ini seperti ketika Anda melakukan pengujian unit nyata menggunakan mock (tanpa ketergantungan pada komponen lain) kelas yang dijelaskan di atas tidak dapat diuji. Tanda dasar dari kode yang tidak dapat diuji adalah sebagian besar mengejek tes karena Anda dipaksa untuk mengejek banyak dependensi (atau situasi)

  2. Tes integrasi - tes yang benar dan bekerja mengatakan kepada Anda bahwa komponen baru Anda (atau komponen) bekerja bersama atau dengan komponen lain - ini adalah definisi biasa. Saya menemukan bahwa sebagian besar tes integrasi membantu Anda menentukan aliran cara menggunakan komponen Anda dari sisi konsumen .

    Ini sangat penting karena kadang-kadang dikatakan kepada Anda bahwa API Anda tidak masuk akal dari luar.

Nah, apa yang terjadi setelah saya menulis tes unit dan tes integrasi nanti?

Saya mendapatkan kelas yang bagus, desain yang jelas, konstruktor yang baik, metode yang pendek dan koheren, IOC siap dll. Setelah saya memberikan kelas / API saya kepada beberapa konsumen, misalnya pengembang dari integrasi atau tim GUI, ia tidak dapat menggunakan API saya karena tampaknya tidak logis , aneh. Dia hanya bingung. Jadi saya memperbaiki API menurut sudut pandangnya tetapi juga diperlukan untuk menulis ulang banyak tes karena saya didorong untuk mengubah metode dan kadang-kadang bahkan aliran cara menggunakan API.

Nah, apa yang terjadi setelah saya menulis tes integrasi dan tes unit nanti?

Saya mendapatkan aliran yang tepat, kegunaan yang baik. Apa yang saya juga miliki adalah kelas besar, kode non-koheren, tidak ada logging, metode panjang. Kode spageti

Apa saran saya?

Saya telah belajar aliran berikut:

  1. Kembangkan kerangka dasar kode Anda
  2. Tulis tes integrasi yang mengatakan apakah masuk akal dari sudut pandang konsumen. Kasus penggunaan dasar sudah cukup untuk saat ini. Tes jelas tidak berhasil.
  3. Tulis kode bersama dengan tes unit untuk setiap kelas.
  4. Tulis sisanya / tidak ada tes integrasi. Akan lebih baik untuk mengimplementasikan tes ini dalam # 3 bagaimana Anda meningkatkan kode Anda.

Perhatikan bahwa saya telah membuat presentasi kecil tentang pengujian unit / integrasi, lihat slide # 21 di mana kerangka dijelaskan.


5

Unit Test digunakan untuk menguji perangkat lunak sekecil mungkin yang dapat diuji dalam suatu aplikasi dan untuk menguji fungsionalitasnya. Setiap unit diuji secara terpisah sebelum menggabungkannya menjadi beberapa bagian atau komponen aplikasi yang lebih besar.

Di situlah Tes Integrasi datang:
Mereka menguji bagian-bagian yang baru dibuat ini yang terdiri dari unit yang diuji sebelumnya selama pemasangan bagian-bagian ini bersama-sama. Kasus terbaik adalah menulis tes pada titik ini saat menulis aplikasi itu sendiri.


Jadi jawaban Anda adalah setelah kode produksi?
Chedy2149

Ini tidak menjawab pertanyaan. Dia bertanya apakah kode produksi ditulis setelah tes integrasi ditulis. Jawaban Anda dapat diambil dengan cara apa pun.
Reactgular

1
@MathewFoscarini - jawaban yang diperbarui. Semoga ini menjadi lebih jelas sekarang.
Ben McDougall

Berkenaan dengan tes unit, saya akan mengambil masalah dengan " sedikit mungkin perangkat lunak". Uji apa yang ada dalam kontrak (misalnya metode publik objek, fungsi yang diekspor perpustakaan) karena kontrak menentukan apa yang harus bekerja. Hal-hal lain dapat diuji, namun tidak hanya membuang-buang waktu tetapi juga kontraproduktif.
itsbruce

3

Saya cenderung melihat tes integrasi sangat mirip dengan tes unit. Dalam hal itu saya memperlakukan subset kode sebagai kotak hitam. Jadi tes integrasi hanyalah sebuah kotak yang lebih besar.

Saya lebih suka menuliskannya sebelum kode produksi. Ini memiliki keuntungan membantu saya mengingat bagian mana yang belum saya pasang atau saya mengubah sedikit detail dalam interaksi objek.


Ada berbagai tingkat pengujian: pengujian komponen kotak putih, pengujian komponen integrasi kotak putih. Pengujian komponen kotak hitam, pengujian integrasi kotak hitam. Ada juga pengujian sistem integrasi.
Alexander.Iljushkin

2

Selain dari tes penerimaan, saya cenderung hanya menulis tes integrasi pada batas-batas aplikasi, untuk memverifikasi bahwa itu terintegrasi dengan baik dengan sistem atau komponen pihak ketiga.

Idenya adalah untuk membuat objek adaptor yang menerjemahkan dari bagaimana pihak ketiga berbicara dengan apa yang dibutuhkan aplikasi Anda, dan menguji penerjemah ini terhadap sistem eksternal yang sebenarnya. Apakah Anda melakukan tes pertama atau tes terakhir adalah saya pikir kurang penting daripada dengan tes unit biasa karena

  • Wawasan desain yang diberikan oleh TDD tidak terlalu penting di sini karena desain sudah cukup dikenal sebelumnya dan biasanya tidak ada yang rumit, Anda hanya memetakan sesuatu dari satu sistem ke sistem lainnya.

  • Bergantung pada modul / sistem yang ingin Anda tangani, itu mungkin memerlukan banyak eksplorasi, pengaturan konfigurasi, persiapan sampel data, yang membutuhkan waktu dan tidak cocok dengan sangat baik dalam loop umpan balik TDD pendek.

Namun, jika Anda benar-benar merasa lebih nyaman membangun adaptor Anda secara bertahap dalam langkah-langkah aman kecil, saya pasti akan merekomendasikan untuk melakukan tes terlebih dahulu, tidak ada salahnya.

Anda dapat menemukan contoh pendekatan ini di sini: http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html (paragraf 6) http://blog.8thlight.com/eric- smith / 2011/10/27 / thats-not-yours.html


di sini Anda berbicara tentang tes integrasi yang memverifikasi interaksi antara "sistem kami" dan perpustakaan pihak ke-3, bagaimana dengan menguji interaksi terhadap platform sambil mengembangkan plug-in misalnya?
Chedy2149

Meskipun saya memiliki sedikit pengalaman dengan pengembangan plugin, saya kira mereka mungkin berbeda karena mereka secara alami sangat erat dengan aplikasi host, jadi Anda mungkin ingin merangkul integrasi itu sepenuhnya dan memutuskan Anda tidak memerlukan lapisan adaptor. Dalam hal ini saya akan sangat berhati-hati tentang kinerja tes - tergantung pada aplikasi host, memanggil API secara langsung dalam sejumlah besar tes Anda bisa sangat lambat. Jika Anda takut akan hal itu, Anda selalu dapat menggunakan pendekatan "lapisan abstraksi tambahan" dan menggunakan tes integrasi tiruan + pada adaptor.
guillaume31

1

Jadi saya akan menerima jawaban pertama tetapi sudah dihapus.
Untuk meringkasnya
Dalam iterasi yang diberikan:

  1. Tulis unit-test
  2. Tulis kode produksi
  3. Tulis tes Integrasi untuk menguji interaksi

Ingat pengujian integrasi sementara 1 dan 2 untuk menjamin testabilitas di tingkat integrasi.

Tes integrasi tidak harus ditulis ujung ke ujung pada langkah 3, tetapi sebagian dapat ditulis antara langkah 1 dan 2.


3
Penjumlahan ini sepenuhnya mengabaikan sifat proses yang berulang. Setelah Anda memiliki API kode produksi Anda stabil hingga tingkat tertentu, Anda dapat mulai menulis tes integrasi. Kemudian Anda dapat mengerjakan kode produksi Anda lagi, dan mungkin mengubah atau memperpanjang tes integrasi Anda. Jadi dalam kebanyakan kasus Anda tidak "menulis tes integrasi setelah kode produksi", Anda biasanya melakukan keduanya secara paralel. Dan sebenarnya, ini sangat tergantung pada jenis perangkat lunak yang Anda gunakan. Pemikiran "Hitam-Putih" tidak membawa Anda lebih jauh.
Doc Brown

Poin bagus. Jawabannya tampaknya mengabaikan sifat desain yang iteratif melalui refactoring.
Chedy2149

0

Tes unit menguji blok kode terpisah dalam proyek Anda.
Tes integrasi menguji bagaimana kode Anda berinteraksi dengan kode lain: dengan kata lain, mereka menguji antarmuka kode Anda.

Tulis pengujian unit saat mengembangkan kode di belakang antarmuka.
Tulis tes integrasi saat mengembangkan antarmuka atau kode apa pun yang mengimplementasikan antarmuka.

Ini berarti bahwa Anda kadang-kadang akan menulis tes integrasi sangat terlambat dalam suatu proyek, karena sebagian besar pekerjaan berada di belakang antarmuka: misalnya, kompiler, layanan web tertentu yang mengimplementasikan beberapa lapisan logika atau .. sesuatu yang melibatkan banyak logika internal.

Namun, jika Anda menerapkan serangkaian layanan REST atau refactoring model data dan menambahkan dukungan untuk transaksi XA, maka Anda akan segera mulai mengembangkan tes integrasi, karena sebagian besar pekerjaan Anda berpusat di sekitar antarmuka, apakah itu API REST atau bagaimana program menggunakan model data.


Apakah Anda setuju untuk mengatakan bahwa pengujian unit adalah pengujian whitebox dan pengujian integrasi adalah pengujian blackbox?
Chedy2149

Sayangnya, itu tergantung. Teknologi untuk pengujian integrasi telah membuat peningkatan besar dalam beberapa tahun terakhir (setidaknya di dunia Java) sehingga saya dapat menguji 1 kelas - tetapi pada server aplikasi. Pertanyaannya kemudian, di mana garis antara tes unit dan tes integrasi? Apakah tes integrasi ketika Anda menguji antarmuka kode Anda dengan teknologi lain, atau apakah tes integrasi ketika Anda menguji seluruh aplikasi Anda - tetapi tidak harus di lingkungan yang seharusnya dijalankan?
Marco

Singkatnya, dalam beberapa kasus, tes integrasi pasti pengujian kotak hitam - tetapi tidak dalam semua kasus.
Marco

FYI: Wiki mendefinisikan pengujian integraion sebagai "fase dalam pengujian perangkat lunak di mana masing-masing modul perangkat lunak digabungkan dan diuji sebagai suatu kelompok"
Marco

Tepat sekali, Marco. Ada integrasi pada setiap level komponen. Level kode, level aplikasi, level sistem.
Alexander.Iljushkin
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.