Perbedaan utama, bagi saya, adalah bahwa tes integrasi mengungkapkan jika suatu fitur berfungsi atau rusak, karena mereka menekankan kode dalam skenario yang mendekati kenyataan. Mereka memanggil satu atau lebih metode atau fitur perangkat lunak dan menguji apakah mereka bertindak seperti yang diharapkan.
Sebaliknya, tes Unit menguji metode tunggal bergantung pada asumsi (sering salah) bahwa sisa perangkat lunak bekerja dengan benar, karena secara eksplisit mengolok-olok setiap ketergantungan.
Oleh karena itu, ketika uji unit untuk metode yang menerapkan beberapa fitur berwarna hijau, itu tidak berarti fitur tersebut berfungsi.
Katakanlah Anda memiliki metode di suatu tempat seperti ini:
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
Log.TrackTheFactYouDidYourJob();
return someResults;
}
DoSomethingsangat penting bagi pelanggan Anda: itu adalah fitur, satu-satunya hal yang penting. Itu sebabnya Anda biasanya menulis spesifikasi Mentimun yang menyatakannya: Anda ingin memverifikasi dan mengkomunikasikan fitur tersebut berfungsi atau tidak.
Feature: To be able to do something
In order to do something
As someone
I want the system to do this thing
Scenario: A sample one
Given this situation
When I do something
Then what I get is what I was expecting for
Tidak diragukan lagi: jika tes lulus, Anda dapat menegaskan bahwa Anda memberikan fitur yang berfungsi. Inilah yang dapat Anda sebut Nilai Bisnis .
Jika Anda ingin menulis tes unit untuk DoSomethingAnda harus berpura-pura (menggunakan beberapa ejekan) bahwa sisa kelas dan metode berfungsi (yaitu: bahwa, semua dependensi yang digunakan metode bekerja dengan benar) dan menegaskan metode Anda berfungsi.
Dalam praktiknya, Anda melakukan sesuatu seperti:
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
return someResults;
}
Anda dapat melakukan ini dengan Injeksi Ketergantungan, atau beberapa Metode Pabrik atau Kerangka Kerja Mock atau memperluas kelas yang sedang diuji.
Misalkan ada bug di Log.DoSomething(). Untungnya, spesifikasi Gherkin akan menemukannya dan tes end-to-end Anda akan gagal.
Fitur tidak akan berfungsi, karena Logrusak, bukan karena [Do your job with someInput]tidak melakukan tugasnya. Dan, omong-omong, [Do your job with someInput]adalah satu-satunya tanggung jawab untuk metode itu.
Juga, anggaplah Logdigunakan dalam 100 fitur lain, dalam 100 metode lain dari 100 kelas lainnya.
Yap, 100 fitur akan gagal. Tetapi, untungnya, 100 tes end-to-end gagal juga dan mengungkapkan masalahnya. Dan, ya: mereka mengatakan yang sebenarnya .
Ini informasi yang sangat berguna: Saya tahu saya memiliki produk yang rusak. Ini juga informasi yang sangat membingungkan: tidak memberi tahu saya tentang di mana masalahnya. Ini mengomunikasikan saya gejala, bukan akar penyebabnya.
Namun, DoSomethingunit test berwarna hijau, karena menggunakan yang palsu Log, dibuat untuk tidak pernah putus. Dan, ya: itu jelas berbohong . Ini mengkomunikasikan fitur yang rusak berfungsi. Bagaimana ini bisa bermanfaat?
(Jika DoSomething()uji unit gagal, pastikan: [Do your job with someInput]memiliki beberapa bug.)
Misalkan ini adalah sistem dengan kelas yang rusak:
Satu bug akan merusak beberapa fitur, dan beberapa tes integrasi akan gagal.
Di sisi lain, bug yang sama akan merusak hanya satu unit test.
Sekarang, bandingkan dua skenario.
Bug yang sama akan merusak hanya satu unit test.
- Semua fitur Anda menggunakan yang rusak
Logberwarna merah
- Semua tes unit Anda berwarna hijau, hanya tes unit untuk
Logyang merah
Sebenarnya, tes unit untuk semua modul menggunakan fitur yang rusak berwarna hijau karena, dengan menggunakan tiruan, mereka menghapus dependensi. Dengan kata lain, mereka berlari di dunia fiksi yang ideal. Dan ini adalah satu-satunya cara untuk mengisolasi bug dan mencari mereka. Pengujian unit berarti mengejek. Jika Anda tidak mengejek, Anda bukan pengujian unit.
Perbedaan
Tes integrasi memberi tahu apa yang tidak berfungsi. Tapi mereka tidak ada gunanya menebak di mana masalahnya.
Tes unit adalah satu-satunya tes yang memberi tahu Anda di mana tepatnya bug itu berada. Untuk menggambar informasi ini, mereka harus menjalankan metode di lingkungan yang diejek, di mana semua dependensi lainnya seharusnya berfungsi dengan benar.
Itu sebabnya saya berpikir bahwa kalimat Anda "Atau itu hanya tes unit yang mencakup 2 kelas" entah bagaimana dipindahkan. Tes unit tidak boleh menjangkau 2 kelas.
Jawaban ini pada dasarnya adalah ringkasan dari apa yang saya tulis di sini: Tes unit berbohong, itu sebabnya saya suka mereka .
