Sekarang mari kita bicara tentang asersi.
Penegasan adalah salah satu hal yang diterima begitu saja, sehingga semua yang ada di sini tampaknya adalah spesialis. Seseorang menggunakan built-in Java atau Junit, seseorang menggunakan perpustakaan canggih, seseorang membangun sendiri.
Tapi mari kita coba pendekatan ini dengan lebih serius. Bagaimana sebenarnya?
Pertama, pernyataan menggandakan spesifikasi. Jika spesifikasi shouldReturnValidOrder ditentukan, maka ini harus diperiksa, dan tidak menegaskanNotNull.
Kedua, pernyataan harus mudah dibaca. Artinya, langsung membandingkan dengan spesifikasinya.
Jika ada terlalu banyak pernyataan (menurut selera saya yang ekstrem, ada lebih dari satu, tetapi kita akan menetapkan batas setidaknya lima hingga tujuh), maka tes tidak lagi dapat dimengerti. Demi kebaikan, setiap tes seharusnya hanya memiliki satu alasan untuk gagal.
Aset dapat diarahkan ke: bidang primitif, objek, koleksi, jarang fungsi atau thunk.
Semakin kompleks objek, semakin kompleks dan beragam pernyataan, dan semakin sulit membaca dan menemukan kesalahan.
Pernyataan positif dibaca lebih baik daripada yang negatif ganda.
Metode standar dibaca lebih baik daripada pembantu kustom. (Siapa yang tahu siapa dan di mana menguji perpustakaan pembantu). Dan pernyataan harus berada di tubuh metode pengujian, dan tidak di suatu tempat di belakang pembantu tes (sonar benar bersumpah pada kurangnya pernyataan).
Aset tentang bidang lebih dimengerti daripada pernyataan tentang objek, dan terutama tentang koleksi.
Dalam kasus bidang bersarang, masuk akal untuk menguji sepenuhnya.
Tidak
assertNotNull(order.getCustomer().getName)
tapi
assertNotNull(order) assertNotNull(order.getCustomer()) assertNotNull(order.getCustomer().getName())
Asser tidak hanya dengan bodoh memeriksa apa yang dikembalikan dari metode, tetapi mempengaruhinya. Dan jika kita bisa mengubahnya, maka kita perlu mengubahnya.
Relatif sulit untuk membuat pernyataan tentang koleksi. Apakah mereka mengandung angka nol, apakah mereka diurutkan, bagaimana tepatnya mereka diurutkan, bagaimana elemen diperiksa untuk kesetaraan, dll. - semua ini membuat koleksi objek sulit untuk pernyataan, terutama ketika ada logika dalam metode yang terkait dengan elemen koleksi.
Oleh karena itu, metode seperti:
List<Order> getOrderList(List<OrderDao> orderDaoList){ return orderDaoList.stream().map(orderDao=>order.name(orderDao.getName).build()).collect(Collectors.toList()) }
mudah untuk dibagi menjadi dua, satu transformator orderDao => memesan dan mengujinya secara terpisah, dan yang kedua akan menguji pemetaan koleksi pada mapper abstrak, dan kita bisa mengujinya pada rintisan.
List<Order> getOrderList(List<OrderDao> orderDaoList, OrderDaoToOrderMapper mapper){ return orderDaoList.stream().map(mapper::map).collect(Collectors.toList()) }
Di sisi lain, koleksi cocok untuk tipifikasi dan ekspansi, mis. kita dapat dengan relatif mudah membuat koleksi jenisnya sendiri dengan semua properti yang diuji, co-dan contravariance, dll. Karena itu, alih-alih Daftar generik, kita bisa membuat Daftar Pesanan kita sendiri, atau OrderSet, atau OrderSortedSet, dan semakin spesifik, semakin baik. Dan tes akan menjadi lebih mudah.
Tidak jauh lebih sulit untuk membuat pernyataan tentang fungsi daripada tentang objek, dan mereka diketik dengan baik dalam beberapa bahasa, sehingga Anda mungkin dapat merekomendasikan pengetikan yang lebih baik, yaitu. alih-alih Func <Order, Order> mengembalikan beberapa OrderComparator.