Tes integrasi, tetapi berapa banyak?


8

Perdebatan terbaru dalam tim saya membuat saya bertanya-tanya. Topik dasarnya adalah seberapa banyak dan apa yang akan kita bahas dengan tes fungsional / integrasi (tentu saja, tidak sama tetapi contohnya adalah tiruan di mana tidak penting).

Katakanlah Anda memiliki kelas "controller" seperti:

public class SomeController {
    @Autowired Validator val;
    @Autowired DataAccess da;
    @Autowired SomeTransformer tr;
    @Autowired Calculator calc;

    public boolean doCheck(Input input) {
        if (val.validate(input)) {
             return false;
        }

        List<Stuff> stuffs = da.loadStuffs(input);
        if (stuffs.isEmpty()) {
             return false;
        }

        BusinessStuff businessStuff = tr.transform(stuffs);
        if (null == businessStuff) {
            return false;
        }

       return calc.check(businessStuff);
    }
}

Kami membutuhkan banyak pengujian unit untuk memastikan (misalnya, jika validasi gagal, atau tidak ada data dalam DB, ...), itu tidak mungkin.

Masalah utama kami dan apa yang tidak kami setujui adalah seberapa banyak tes integrasi akan mencakupnya :-)

Saya berada di pihak yang kita akan bertujuan untuk tes integrasi kurang (test pyramid). Apa yang akan saya bahas dari ini hanyalah satu jalan bahagia-bahagia di mana eksekusi kembali dari baris terakhir, hanya untuk melihat apakah saya menyatukan hal-hal ini tidak akan meledak.

Masalahnya adalah tidak mudah untuk mengatakan mengapa tes menghasilkan false, dan itu membuat beberapa orang merasa tidak nyaman tentang hal itu (misalnya, jika kita hanya memeriksa hanya nilai pengembalian, disembunyikan bahwa tes berwarna hijau karena seseorang mengubah validasi dan mengembalikan false). Tentu, ya, kita bisa membahas semua kasus tetapi itu akan menjadi imho yang terlalu berat.

Apakah ada yang punya aturan praktis yang baik untuk masalah seperti ini? Atau rekomendasi? Bacaan? Berbicara? Posting blog? Ada topik apa saja?

Terima kasih banyak sebelumnya!

PS: Coba contoh jelek tapi cukup sulit untuk menerjemahkan bagian kode tertentu ke contoh. Ya, orang dapat berdebat tentang melempar pengecualian / menggunakan tipe pengembalian yang berbeda / dll. tetapi tangan kita lebih atau kurang terikat karena ketergantungan eksternal.

PS2: Saya memindahkan topik ini dari SO di sini (pertanyaan awal, ditandai ditahan )

Jawaban:


6

Ada sekolah pemikiran yang secara serius mempertanyakan nilai tes integrasi.

Saya menduga Anda akan mendapatkan spektrum jawaban yang luas di sini, tetapi menurut saya Anda hanya boleh menggunakannya ketika mereka memberikan nilai yang jelas.

Pertama, Anda harus menulis sebanyak mungkin unit test, karena a) harganya murah dan b) mungkin hanya tes yang berjalan di build server (harus ada).

Sangat menggoda untuk menulis tes sisi klien untuk memverifikasi basis data atau lapisan lain, tetapi ini harus benar-benar terjadi pada tingkat yang sesuai jika mungkin daripada membuat tes integrasi. Ini tentu saja dapat memerlukan beberapa dasar dalam bentuk antarmuka dll untuk mendapatkan mengejek dan sejenisnya berfungsi.

Pertimbangkan juga ruang lingkup pengujian Anda. Jika Anda hanya menulis tes integrasi untuk menutupi apa yang terjadi ketika suite Anda dijalankan atau menduplikasi tes asap, maka ini memiliki nilai terbatas. Juga, pikirkan apakah lebih banyak masuk ke tempat-tempat terkait akan menjadi pilihan yang lebih baik daripada mendapatkan pesan yang tidak jelas dari selusin komponen yang saling berhubungan dan harus melacaknya melalui.

Jadi dengan asumsi Anda telah memutuskan untuk menulis beberapa, Anda perlu memikirkan kapan mereka akan menjalankannya. Jika mereka dapat menangkap beberapa masalah buruk yang terjadi, maka itu bagus, tetapi itu menjadi sangat tidak berguna jika pengembang tidak pernah ingat untuk menjalankannya.

Akhirnya, tes integrasi adalah pengganti yang sama sekali tidak cocok untuk pengujian asap dan pengujian pengguna. Jika Anda benar-benar peduli dengan mereka, mereka harus membentuk sebagian kecil dari proses pengujian yang dirancang dengan baik.


4
Hanya komentar: perhatikan bahwa, sebaliknya, ada aliran pemikiran yang secara serius mempertanyakan nilai tes unit (DHH mengklaim mempertanyakan TDD, tetapi jika Anda membaca posnya, ia juga mempertanyakan tes unit). Sejujurnya, saya menemukan hal-hal yang setuju dan tidak setuju dengan kedua aliran pemikiran ekstremis :)
Andres F.

1
Banyak dogma di sekitar TDD ada di sekitar tidak menulis apa pun yang Anda tidak perlu yang tahu pengembang berpengalaman melalui YAGNI ...
Robbie Dee

4
Jawaban Anda baik-baik saja (1), artikel Anda dikutip, bagaimanapun, memiliki masalah yang penulis memberikan kesan hanya karena tes integrasi tidak bekerja untuk itu kasus, mereka tidak akan bekerja untuk orang lain. Di tim kami, kami menggunakan tes integrasi di sini untuk produk kami selama lebih dari 10 tahun dalam praktiknya, dan mereka mencegah kami menyebarkan bug parah berkali-kali, jadi saya pikir sebenarnya mungkin untuk menulis tes integrasi yang menghasilkan nilai tinggi.
Doc Brown

Penulis juga menulis dalam komentar "Tes terintegrasi (bukan" tes integrasi "!) [...]" - Saya tidak yakin tentang perbedaannya tetapi bagi saya tampaknya ada banyak nuansa yang terlibat dalam apakah tes integrasi dilakukan. bermanfaat atau bagus.
Carson Myers

Dalam pengalaman saya, hanya tes integrasi yang benar-benar memberikan nilai. Tes unit, khususnya yang menggunakan ejekan, lebih banyak masalah daripada nilainya. Dalam proyek saya saat ini, misalnya, kami memiliki 650 tes integrasi berbasis JUnit yang berjalan pada setiap komit di server Jenkins, dengan pembangunan penuh membutuhkan waktu kurang dari 10 menit. Tentu saja, kami juga menjalankan tes pada IDE kami, sambil melakukan TDD. Kami tidak melihat perlunya memiliki rangkaian uji unit tambahan - ini akan menambah lebih banyak upaya tanpa hasil yang nyata. Mungkin alasan beberapa pengembang menghindari tes integrasi adalah karena mereka belum benar-benar mencoba?
Rogério

8

Bertentangan dengan jawaban ini , saya menemukan pengujian pada tingkat yang berbeda merupakan bagian penting dari proses pengujian perangkat lunak. Unit, fungsional, integrasi, asap, penerimaan, dan jenis pengujian lainnya menguji berbagai hal, dan semakin sering semakin meriah.

Dan jika Anda berhasil mengotomatisasi mereka, maka mereka dapat dieksekusi sebagai pekerjaan integrasi berkelanjutan Anda (seperti jenkins). Tidak ada yang perlu mengeksekusi mereka untuk melihat apakah mereka rusak, karena semua orang dapat melihat apakah tes gagal.

Dalam tes integrasi saya, saya tidak masuk ke detail - detail dan kasing sudut adalah untuk tes unit. Apa yang saya uji hanyalah fungsi utama, melewati semua parameter yang benar. Itu berarti, dalam contoh Anda, dalam tes integrasi, saya tidak akan menutupi jalur yang salah.


1
+1 Yap, jika Anda dapat melakukan tes integrasi dalam build maka jauh lebih baik tetapi ini bisa menjadi upaya signifikan dalam solusi tingkat perusahaan.
Robbie Dee
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.