Haruskah itu "Atur-Tegaskan-Undang-Undang"?

Mengenai pola pengujian klasik Arrange-Act-Assert , saya sering menemukan diri saya menambahkan pernyataan balasan yang mendahului Act. Dengan cara ini saya tahu bahwa pernyataan kelulusan benar-benar lulus sebagai hasil dari tindakan tersebut.

Saya menganggapnya sebagai analogi dengan merah dalam merah-hijau-refactor, di mana hanya jika saya telah melihat bilah merah selama pengujian saya, saya tahu bahwa bilah hijau berarti saya telah menulis kode yang membuat perbedaan. Jika saya menulis tes lulus, maka kode apa pun akan memuaskannya; demikian pula, sehubungan dengan Arrange-Assert-Act-Assert, jika pernyataan pertama saya gagal, saya tahu bahwa Undang-undang apa pun akan lolos Assert akhir - sehingga tidak benar-benar memverifikasi apa pun tentang Undang-undang tersebut.

Apakah tes Anda mengikuti pola ini? Mengapa atau mengapa tidak?

Klarifikasi Pembaruan : pernyataan awal pada dasarnya adalah kebalikan dari pernyataan akhir. Ini bukan pernyataan bahwa Atur berhasil; itu adalah pernyataan bahwa Undang-undang belum berhasil.

Ini bukanlah hal yang paling umum untuk dilakukan, tetapi masih cukup umum untuk memiliki namanya sendiri. Teknik ini disebut Guard Assertion . Anda dapat menemukan penjelasan mendetailnya di halaman 490 di buku xUnit Test Patterns yang sangat bagus oleh Gerard Meszaros (sangat disarankan).

Biasanya, saya tidak menggunakan pola ini sendiri, karena saya merasa lebih tepat untuk menulis pengujian khusus yang memvalidasi prasyarat apa pun yang saya rasa perlu dipastikan. Pengujian seperti itu seharusnya selalu gagal jika prasyarat gagal, dan ini berarti saya tidak memerlukannya disematkan di semua pengujian lainnya. Ini memberikan isolasi masalah yang lebih baik, karena satu kasus pengujian hanya memverifikasi satu hal.

Mungkin ada banyak prasyarat yang perlu dipenuhi untuk kasus pengujian tertentu, jadi Anda mungkin memerlukan lebih dari satu Pernyataan Penjaga. Daripada mengulanginya di semua pengujian, memiliki satu (dan satu-satunya) pengujian untuk setiap prasyarat membuat kode pengujian Anda lebih dapat dipertahankan, karena dengan cara itu Anda akan memiliki lebih sedikit pengulangan.

Hal ini juga bisa ditetapkan sebagai Arrange- Asumsikan -Act-Tegaskan.

Ada pegangan teknis untuk ini di NUnit, seperti pada contoh di sini: http://nunit.org/index.php?p=theory&r=2.5.7

Berikut contohnya.

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
    range.encompass(7);
    assertTrue(range.includes(7));
}

Bisa jadi saya menulis Range.includes()untuk sekadar membalas dengan benar. Saya tidak melakukannya, tetapi saya dapat membayangkan bahwa saya mungkin akan melakukannya. Atau saya bisa saja salah menuliskannya dengan berbagai cara lain. Saya berharap dan berharap bahwa dengan TDD saya benar-benar melakukannya dengan benar - itu includes()hanya berfungsi - tetapi mungkin saya tidak. Jadi pernyataan pertama adalah pemeriksaan kewarasan, untuk memastikan bahwa pernyataan kedua benar-benar bermakna.

Membaca dengan sendirinya, assertTrue(range.includes(7));mengatakan: "menegaskan bahwa rentang yang dimodifikasi mencakup 7". Baca dalam konteks pernyataan pertama, itu mengatakan: "menegaskan bahwa memanggil encompass () menyebabkannya menyertakan 7. Dan karena mencakup adalah unit yang kita uji, saya pikir itu dari beberapa nilai (kecil).

Saya menerima jawaban saya sendiri; banyak yang lain salah menafsirkan pertanyaan saya tentang pengujian pengaturan. Saya rasa ini sedikit berbeda.

Sebuah Arrange-Assert-Act-Asserttes selalu bisa refactored menjadi dua tes:

1. Arrange-Assert

dan

2. Arrange-Act-Assert

Tes pertama hanya akan menegaskan apa yang telah diatur di fase Atur, dan tes kedua hanya akan menegaskan apa yang terjadi di fase Act.

Ini memiliki keuntungan memberikan umpan balik yang lebih tepat tentang apakah itu fase Atur atau Tindakan yang gagal, sementara dalam aslinya Arrange-Assert-Act-Assertini digabungkan dan Anda harus menggali lebih dalam dan memeriksa dengan tepat pernyataan apa yang gagal dan mengapa itu gagal untuk mengetahui apakah itu adalah Arrange atau Act yang gagal.

Ini juga memenuhi maksud pengujian unit dengan lebih baik, karena Anda memisahkan pengujian Anda menjadi unit independen yang lebih kecil.

Terakhir, perlu diingat bahwa setiap kali Anda melihat bagian Atur yang serupa dalam pengujian yang berbeda, Anda harus mencoba menarik ini ke dalam metode pembantu bersama, sehingga pengujian Anda lebih KERING dan lebih dapat dipelihara di masa mendatang.

Saya sekarang melakukan ini. AAAA dari jenis yang berbeda

Arrange - setup
Act - what is being tested
Assemble - what is optionally needed to perform the assert
Assert - the actual assertions

Contoh tes pembaruan:

Arrange: 
    New object as NewObject
    Set properties of NewObject
    Save the NewObject
    Read the object as ReadObject

Act: 
    Change the ReadObject
    Save the ReadObject

Assemble: 
    Read the object as ReadUpdated

Assert: 
    Compare ReadUpdated with ReadObject properties

Alasan agar ACT tidak memuat pembacaan ReadUpdated adalah karena bukan bagian dari undang-undang tersebut. Tindakan itu hanya mengubah dan menyelamatkan. Jadi sungguh, ARRANGE ReadUpdated untuk penegasan, saya menelepon ASSEMBLE untuk pernyataan. Ini untuk mencegah kebingungan bagian ARRANGE

ASSERT hanya boleh berisi pernyataan. Itu meninggalkan ASSEMBLE antara ACT dan ASSERT yang menyiapkan assert.

Terakhir, jika Anda gagal dalam Atur, tes Anda tidak benar karena Anda harus memiliki tes lain untuk mencegah / menemukan bug sepele ini . Karena untuk skenario yang saya sajikan, seharusnya sudah ada tes lain yang menguji READ dan CREATE. Jika Anda membuat "Penjaga Pernyataan", Anda mungkin melanggar KERING dan membuat pemeliharaan.

Melempar pernyataan "pemeriksaan kewarasan" untuk memverifikasi status sebelum Anda melakukan tindakan yang Anda uji adalah teknik lama. Saya biasanya menulisnya sebagai perancah uji untuk membuktikan kepada diri saya sendiri bahwa tes tersebut melakukan apa yang saya harapkan, dan menghapusnya nanti untuk menghindari tes yang berantakan dengan perancah uji. Terkadang, membiarkan perancah membantu ujian berfungsi sebagai naratif.

Saya sudah membaca tentang teknik ini - mungkin dari Anda btw - tapi saya tidak menggunakannya; terutama karena saya terbiasa dengan bentuk triple A untuk pengujian unit saya.

Sekarang, saya menjadi penasaran, dan memiliki beberapa pertanyaan: bagaimana Anda menulis tes Anda, apakah Anda menyebabkan pernyataan ini gagal, mengikuti siklus refactor merah-hijau-merah-hijau, atau apakah Anda menambahkannya setelah itu?

Apakah Anda terkadang gagal, mungkin setelah Anda melakukan refaktorisasi kode? Apa artinya ini untuk Anda? Mungkin Anda dapat membagikan contoh di mana itu membantu. Terima kasih.

Saya telah melakukan ini sebelumnya ketika menyelidiki tes yang gagal.

Setelah banyak garukan kepala, saya memutuskan bahwa penyebabnya adalah metode yang disebut selama "Atur" tidak berfungsi dengan benar. Kegagalan pengujian menyesatkan. Saya menambahkan Assert setelah mengatur. Ini membuat pengujian gagal di tempat yang menyoroti masalah sebenarnya.

Saya rasa ada juga code bau di sini jika bagian Atur tes terlalu panjang dan rumit.

Secara umum, saya sangat menyukai "Atur, Bertindak, Tegaskan" dan menggunakannya sebagai standar pribadi saya. Namun, satu hal yang tidak dapat saya ingatkan untuk saya lakukan adalah mengacaukan apa yang telah saya atur ketika penegasan selesai. Dalam kebanyakan kasus, ini tidak menyebabkan banyak gangguan, karena sebagian besar hal secara otomatis menghilang melalui pengumpulan sampah, dll. Jika Anda telah membuat koneksi ke sumber daya eksternal, Anda mungkin ingin menutup koneksi tersebut setelah selesai. dengan pernyataan Anda atau Anda banyak yang memiliki server atau sumber daya mahal di luar sana yang berpegang pada koneksi atau sumber daya penting yang seharusnya dapat diberikan kepada orang lain. Ini sangat penting jika Anda adalah salah satu pengembang yang tidak menggunakan TearDown atau TestFixtureTearDownuntuk membersihkan setelah satu atau lebih tes. Tentu saja, "Atur, Bertindak, Tegaskan" tidak bertanggung jawab atas kegagalan saya untuk menutup apa yang saya buka; Saya hanya menyebutkan "gotcha" ini karena saya belum menemukan sinonim "A-word" yang baik untuk "dispose" untuk direkomendasikan! Ada saran?

Lihat entri Wikipedia di Design by Contract . Holy Trinity Arrange-Act-Assert adalah upaya untuk menyandikan beberapa konsep yang sama dan tentang membuktikan kebenaran program. Dari artikel:

The notion of a contract extends down to the method/procedure level; the
contract for each method will normally contain the following pieces of
information:

    Acceptable and unacceptable input values or types, and their meanings
    Return values or types, and their meanings
    Error and exception condition values or types that can occur, and their meanings
    Side effects
    Preconditions
    Postconditions
    Invariants
    (more rarely) Performance guarantees, e.g. for time or space used

Ada pertukaran antara jumlah upaya yang dihabiskan untuk menyiapkan ini dan nilai yang ditambahkannya. AAA adalah pengingat yang berguna untuk langkah-langkah minimum yang diperlukan, tetapi tidak boleh menghalangi siapa pun untuk membuat langkah tambahan.

Bergantung pada lingkungan / bahasa pengujian Anda, tetapi biasanya jika sesuatu di bagian Atur gagal, pengecualian dilemparkan dan pengujian gagal menampilkannya alih-alih memulai bagian Undang-undang. Jadi tidak, saya biasanya tidak menggunakan bagian Assert kedua.

Juga, jika bagian Atur Anda cukup kompleks dan tidak selalu mengeluarkan pengecualian, Anda mungkin mempertimbangkan untuk membungkusnya di dalam beberapa metode dan menulis tes sendiri untuk itu, sehingga Anda dapat yakin itu tidak akan gagal (tanpa melempar pengecualian).

Saya tidak menggunakan pola itu, karena menurut saya melakukan sesuatu seperti:

Arrange
Assert-Not
Act
Assert

Mungkin tidak ada gunanya, karena seharusnya Anda tahu bagian Atur Anda berfungsi dengan benar, yang berarti bahwa apa pun yang ada di bagian Atur harus diuji juga atau cukup sederhana sehingga tidak memerlukan pengujian.

Menggunakan contoh jawaban Anda:

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7)); // <-- Pointless and against DRY if there 
                                    // are unit tests for Range(int, int)
    range.encompass(7);
    assertTrue(range.includes(7));
}

Jika Anda benar-benar ingin menguji semuanya dalam contoh, coba tes lainnya ... seperti:

public void testIncludes7() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
}

public void testIncludes5() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(5));
}

public void testIncludes0() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(0));
}

public void testEncompassInc7() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(7));
}

public void testEncompassInc5() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(5));
}

public void testEncompassInc0() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(0));
}

Karena jika tidak, Anda kehilangan begitu banyak kemungkinan kesalahan ... misalnya setelah mencakup, kisaran hanya mencakup 7, dll ... Ada juga tes untuk jarak jangkauan (untuk memastikan itu tidak juga mencakup nilai acak), dan serangkaian pengujian lainnya sepenuhnya untuk mencoba mencakup 5 dalam rentang ... apa yang akan kami harapkan - pengecualian dalam cakupan, atau rentang tidak diubah?

Pokoknya, intinya adalah jika ada asumsi dalam tindakan yang ingin Anda uji, uji sendiri, ya?

Saya menggunakan:

1. Setup
2. Act
3. Assert 
4. Teardown

Karena penyiapan yang bersih sangat penting.