Anotasi

Artikel tersebut berbicara tentang bentuk tes yang tidak konvensional, tetapi bermanfaat, dan juga merangkum hasil tujuh tahun kerja dalam pengembangan tes.

Mengapa Anda memerlukan tes komponen?

Bagaimanapun, ada, katakanlah, unit test yang menguji secara detail jeroan komponen. Mereka benar-benar memverifikasi bahwa komponen bekerja sesuai dengan maksud pengembang. Namun seringkali ini merupakan cek tombol, dan bukan bagaimana setelannya secara keseluruhan berada. Dan tidak selalu perilaku yang dikandung oleh programmer bertepatan dengan apa yang diinginkan pelanggan.

Dan ada, misalnya, tes penerimaan. Dan mereka menghilangkan semua kekurangan ini. Namun, sayangnya, mereka memperkenalkan yang baru. Mereka lambat, sering tidak stabil, dan biasanya jinak. Namun, mereka hanya menunjukkan masalah, tetapi tidak melokalkannya.

Jelas, perlu muncul untuk tes menengah, yang akan menjadi rata-rata emas antara tes unit dan penerimaan. Jalan tengah ini mungkin merupakan tes komponen.

Apa itu tes komponen?

Ini adalah tes untuk API komponen publik. Dengan demikian, mereka ditulis dalam bahasa yang sama dengan komponen. Tujuan Tes:

• verifikasi kepatuhan komponen dengan kontrak Anda
• periksa kepatuhan
  Yang terakhir ini sangat penting sejak itu unit test biasanya ditulis berdasarkan harapan pengembang, tetapi di sini Anda perlu memeriksa harapan pelanggan.

Jelas, tes komponen masuk akal ketika Anda memiliki komponen khusus dengan antarmuka yang luas. Misalnya, perpustakaan dinamis atau objek COM. Kemudian tes komponen akan memberikan efek maksimal.

Pro-tes k:

• Berikan stabilitas untuk pembangunan. Jelas, pemeriksaan komprehensif antarmuka publik memungkinkan Anda untuk menjaga komponen dalam bentuk yang lebih atau kurang efisien.
• Secara akurat melokalisasi masalah. Bahkan jika tes komponen itu sendiri cukup umum, itu selalu dapat didebug secara mendalam, dengan cepat mencapai kode pertempuran. Dalam hal ini, lingkungan pengujian akan minimal dan secara otomatis dikonfigurasi.
• Mempercepat pengembangan dengan sejumlah pengembang yang kritis. Programmer dikenal seperti kuda. Jika seekor kuda menarik kereta dengan kapasitas 1 liter. s., kemudian delapan kuda ditarik dengan kapasitas hanya sekitar 4 liter. s Dan penambahan pengembang lain ke tim (terutama di akhir proyek) sering tidak hanya tidak mempercepat, tetapi juga memperlambatnya. Sementara penambahan pengembang uji komponen selalu merupakan nilai tambah, karena ia bertindak relatif independen dari tim: ia melakukan tes (pada dasarnya eksternal), mempercepat pembangunan build, mengoptimalkan file assembly, dll.
• Perjelas (dan kemudian verifikasi) persyaratan pelanggan. Karena pengembang tes komponen tidak terikat pada implementasi, ia kurang terpengaruh oleh efek "Saya tahu bagaimana melakukannya sendiri". Dalam hal persyaratan yang ambigu, pengembang biasa cenderung melakukannya dengan nyaman (lebih menarik, lebih cepat, lebih mudah). Sedangkan ct-developer dalam hal ini cenderung menentukan apa yang sebenarnya diharapkan oleh pelanggan.
• Relatif stabil dan relatif cepat (dibandingkan dengan tes manual dan tes otomatis melalui antarmuka pengguna).

Kontra dari K-tes:

• Waktu untuk pengembangan dan dukungan. Jelas, versi alpha produk, jika sebagian waktu dihabiskan untuk menulis tes komponen, akan muncul nanti. Apakah akan ada keuntungan secara umum? Apakah akan ada rilis lebih cepat? Ini pertanyaan yang bagus. Pendapat saya: ketika mengembangkan dengan tes komponen, rilis akan dirilis pada waktu yang hampir bersamaan. Tapi - dengan rumor yang lebih sedikit dan lebih mudah diprediksi dari segi waktu. Waktu pengembangan secara alami akan meningkat, waktu perbaikan bug dan stabilisasi akan berkurang. Karena bagian kedua jauh kurang dapat diprediksi, pengurangannya akan memiliki efek menguntungkan pada jumlah pemrosesan dan kerumitan. Namun, ini hanya pengalaman saya, dan kenyataannya mungkin berbeda. Ada kemungkinan bahwa waktu yang dialokasikan untuk pengujian komponen akan tidak layak dihabiskan untuk menduplikasi pengujian unit yang ada.
• Kurang dipertukarkan. Pemisahan peran meningkatkan efisiensi, tetapi mengurangi pertukaran. Pengembang jarang ingin masuk jauh ke dalam pengujian komponen, yang dapat memiliki (atau mensimulasikan) lingkungan yang cukup kompleks. Para pengembang tes komponen jauh dari mengetahui kode pertempuran dengan baik sehingga dapat dengan mudah diedit.
• Duplikasi yang menjengkelkan. Dengan tes unit yang baik, uji komponen sering berubah menjadi kebanyakan berlebihan. Ini menjengkelkan dan mempertanyakan kebutuhan mereka. Koordinasi rencana unit dan pengujian komponen membantu, tetapi biasanya duplikasi tidak sepenuhnya dihilangkan.
• Kebutuhan untuk mengikuti alur kerja yang benar. Setelah menerima persyaratan, tugas harus dilakukan secara bersamaan pada pengembang dan pengembang tes. Kemudian mereka selesai bekerja pada waktu yang hampir bersamaan. Komponen dijalankan melalui pengujian, kesalahan dengan cepat ditangkap dan diperbaiki, dan produk jadi lebih atau kurang digunakan untuk keluar. Dalam hal ini, manfaat dari pengujian komponen dimaksimalkan. Tetapi sering terjadi bahwa tenggat waktu lama tidak senonoh, semua ditinggalkan untuk menulis kode saja, dan komponen dikirim ke pengujian manual tanpa tes. Dan hanya pada saat itu mereka mengundang pengembang tes - mereka mengatakan itu tidak baik bahwa kode tanpa tes telah dirilis, perlu menambahkannya. Dalam hal ini, sebagian besar bug adalah penguji genggam, pengembang membuat koreksi secara membabi buta (atau menguji pengeditan sendiri dengan tangan mereka), dan tes post-factum hanya menemukan sejumlah kecil kesalahan (yang secara negatif mempengaruhi moral penulis mereka). Penggunaan tes komponen seperti itu tidak berguna sama sekali, dan sulit untuk memastikannya.
• Ada beberapa orang yang cocok. Pengembang tes komponen harus, di satu sisi, dapat menulis kode dalam bahasa komponen (dan ini, misalnya, C ++). Selain itu, jika lingkungan untuk meluncurkan komponen sangat luas, kodenya bisa sangat rumit. Dan di sisi lain, dapat dengan cermat menguji pekerjaan orang lain. Tidak banyak orang seperti itu, dan mereka biasanya langsung pergi ke pengembang. Tetapi masih ada orang-orang seperti itu, dan bagian selanjutnya tentang mereka.

Ringkasan 1

Tes komponen baik, tetapi hanya jika Anda memiliki semua kondisi untuk mereka: API publik yang luas, alur kerja yang tepat, dan orang yang tepat dalam tim.

Seperti apa rasanya menjadi SDET?

Jelas, SDET - Software Development Engineer dalam Test adalah kandidat yang ideal untuk menulis tes komponen. Dia tahu cara menulis kode, dan tahu cara berpikir dalam ujian. Ini juga memberikan pendapat kedua, yang juga meningkatkan kualitas tes dan kode. Semua ini terdengar menarik dan menggoda - mungkin Anda sudah ingin menjadi satu. Di sini saya secara singkat akan memberi tahu Anda bagaimana pekerjaan SDET berbeda dari pekerjaan pengembang murni.

Keuntungan bekerja dengan SDET:

• Kode baru Hampir selalu, SDET menulis tes dari awal. Dan cukup sering, suatu lingkungan ditulis dari awal. Ini sangat bagus dan memberi ruang besar untuk kreativitas.
• Ketergantungan yang rendah pada kode sebelumnya. Tidak peduli seberapa buruk kode pertempuran itu, tes untuk itu dapat dilakukan dengan kompeten dan indah. Tentu saja, kode yang dirancang dengan buruk menghasilkan tes yang jelek, tetapi tetap saja mereka dapat dibuat urutan besarnya lebih baik daripada kode itu sendiri.
• Refactoring yang lebih sering. Perubahan dalam tes jauh lebih tidak berbahaya, oleh karena itu, mereka lebih sering disetujui. Ini adalah peluang bagus untuk mengatasi bug dan berlatih menulis kode bersih melalui refactoring.
• Perkembangan pemikiran kritis. Autotests adalah pencarian menarik untuk memecahkan kode orang lain. Selain itu, pencarian tidak bodoh, tidak duduk dan menyodok, tetapi dengan bantuan logika, kombinatorik dan kemampuan untuk melihat kerentanan. Ditambah sekali dibuat cek akan terus bekerja untuk Anda secara konstan.
• Mengembangkan kemampuan untuk menguji kode. Dalam pelatihan tempur tangan-ke-tangan, mereka sering memberikan kata-kata pengantar: "sekarang kita hanya bekerja dengan kaki kita; sekarang kita hanya bekerja dengan kepala kita." Hanya menggunakan satu mekanisme (dalam kasus kami, autotes) memungkinkan Anda untuk mengasahnya untuk penguasaan.
• Jumlah rumor lebih sedikit. SDET ditarik jauh lebih sedikit untuk akhir pekan. Mereka tidak harus segera bekerja untuk memperbaiki bug yang kritis. Yah, mereka memiliki peluang jauh lebih rendah untuk melakukan kesalahan serius.

Kontra bekerja dengan SDET:

• Kompleksitas coding rendah. Kode tes biasanya masih lebih sederhana daripada kode pertempuran. Prasyarat, memanggil kode pertempuran, postkondisi - dan seterusnya untuk setiap tes. Kode untuk menciptakan lingkungan lebih rumit, tetapi masih belum mencapai pertempuran. Pemilihan algoritma yang optimal, merancang struktur data yang kompleks, membangun hierarki kelas - biasanya semua ini dilewati oleh pengembang pengujian.
• Pengalaman semakin lambat . Variasi dan kompleksitas situasi di mana pengembang tes jatuh jauh lebih sedikit. Kegagalan jalur perakitan, tes merah, kadang-kadang dump - ini adalah set utama yang biasanya harus Anda kerjakan. Pengembang memiliki jauh lebih banyak masalah: mulai dari menghubungkan dan variasi perakitan, melanjutkan dengan gangguan pada pelanggan tertentu dan membuat dump, berakhir dengan mencari bug di kompiler dan perpustakaan pihak ketiga. Dan tidak hanya ...
• Perbedaan utama dalam gaya pengujian dengan pengembang. Biasanya, SDET lebih suka tes ekspresif kompak yang memungkinkan Anda untuk membuat lingkungan yang kompleks hanya dalam beberapa baris, dan pemeriksaan atom dalam gaya sama / tidak sama (yaitu, persyaratan terpenuhi atau tidak). Kadang-kadang datang ke DSL-nya. Sederhananya, pengembang lebih suka tes dengan menyesuaikan lingkungan dan berbagai tes dari berbagai aspek perilaku program, yang mengarah ke tes multi-line. Kadang-kadang menyangkut copy-paste (yang bahkan pengembang terbaik tidak menganggap dosa dalam kasus ini). Di sini Anda dapat berdiskusi lama tentang cara terbaik atau bahkan menulis artikel terpisah, tetapi faktanya adalah ketika pengembang mencoba memodifikasi tes SDET (atau sebaliknya), ini sering mengarah pada diskusi yang panjang dan tidak efektif.
• Di bawah ini adalah "kelas". Mungkin karena kode lebih sederhana dan kurang tanggung jawab, tetapi pada akhirnya tidak penting. Biasanya seperti itu.
• Lebih sulit untuk pindah ke posisi baru. SDET mungkin mendapatkan pertanyaan di dahi: Anda telah menulis tes begitu lama, yaitu, sebenarnya, Anda baru saja memanggil fungsi dan membandingkan hasilnya - dapatkah Anda menulis kode nyata? Apakah Anda tahu semua perangkap bahasa? Apakah Anda memecahkan masalah yang rumit? Apakah Anda harus membongkar bug atau dump berornamen? Apakah ada pengalaman dengan multithreading? Apakah Anda, bagaimanapun, memiliki ambisi?

Ringkasan 2

Sebagai orang yang bekerja sebagai pengembang selama bertahun-tahun, kemudian pergi ke SDET selama beberapa tahun, dan kemudian kembali ke pengembangan lagi, saya dapat mengatakan yang berikut.

Saya sangat merekomendasikan menghabiskan SDET untuk setidaknya satu atau dua tahun. Ini adalah pengalaman yang sangat berharga bagi pengembang mana pun. Tetapi untuk tinggal di sana, menurut saya, tidak sepadan.