Memilih nama untuk tes integrasi

13

Dengan unit test domainnya cukup kecil, jadi mudah. Saya menggunakan methodName_conditions_result()skema Osherove dan merasa sangat jelas.

Tetapi dengan tes integrasi saya merasa itu akan membuat nama yang sangat panjang, dan apa yang saya tempatkan methodName? Bagaimana cara memberi nama kelas tes integrasi?

Contoh nyata dari dunia nama uji integrasi sangat disambut baik. Saya berharap jawabannya juga akan membantu saya untuk lebih memahami tes ini.

testing naming integration-tests

— batu besar
sumber

1

mengapa pertanyaan ini dibatalkan (dua kali)?

— bigstones

6

Saya mengambil pendekatan yang sedikit berbeda dengan tes unit dan integrasi. Saya mencoba memberi nama mereka berdasarkan fitur sebanyak mungkin. Kemudian ketika semua tes lulus Anda dapat melihat daftar semua fitur yang berfungsi dan tidak berfungsi.

canRegisterUser
canHandleInvalidInput
canRelayDocumentBetweenServers
canCreateSchema
canLoginUsingWebService
canLoginUsingBasicAuth
canDeleteDocument
canAddDocument

Tidak selalu pragmatis untuk menyebutkan tes dengan cara ini, tetapi ini bisa sangat membantu terutama setelah membaca ratusan unit dan tes integrasi. Secara keseluruhan nama Kelas yang mencakup metode ini juga harus menunjukkan fitur yang sedang diuji. Ini akan membantu organisasi.

Saya juga menyarankan memberi nama unit test untuk perbaikan bug dengan awalan unik seperti bugfix1002untuk membuktikan bahwa bug telah diperbaiki.

— Andrew T Finnell
sumber

5

Ini benar-benar ditulis untuk membantu dengan tes unit, tetapi mungkin Anda akan menemukan bahwa aturan yang sama berlaku (kurang lebih) untuk tes integrasi:

Lihatlah Tujuh Langkah !

Preferensi saya adalah apa pun yang Anda sebut, itu benar-benar nama suite uji (nama fixture pada kartu kami), efek yang Anda periksa, dan pesan pernyataan yang perlu menonjol dan membuat penyebab kesalahan menjadi jelas. Jika Anda menemukan itu paling mudah dengan penamaan Asherove, maka saya dengan sepenuh hati mendukungnya. Tapi mungkin triknya adalah Anda mengisi bagian "metode" dengan apa pun yang membuat kondisi, hasil, dan pengecualian masuk akal.

Saya senang melihat suite bernama "MakingADeposit" dengan tes yang disebut "AccountDoesntExist" dan kesalahan yang mengatakan "Diharapkan pengecualian NonesuchAccount - tidak ada yang diterima."

Atau jika Anda tidak keberatan memisahkan nama test suite dengan "::", saya setuju dengan "AccountHandling :: MakingADeposit_AccountDoesntExist_ThrowsAnException"

Kartu ini juga menunjukkan bahwa jika Anda tidak memiliki nama baik, lanjutkan dan berikan nama yang lebih baik ketika salah satu terjadi pada Anda (mudah-mudahan sebelum mengirimkan kode ke CI).

— tottinge
sumber

2

Tes integrasi harus mengikuti beberapa aturan yang serupa dengan pengujian unit karena setiap pengujian harus menguji satu aspek persyaratan tetapi menguji sistem secara keseluruhan. Kelas harus memberi nama keseluruhan hal yang sedang diuji, misalnya "TpcInputValidation" dan penamaan metode harus mencerminkan secara eksplisit apa yang coba dilakukan pengujian tanpa terlalu bertele-tele, misalnya "shouldRaiseValidationErrorWithBadDates ()".

Metode harus menguji satu konsep fitur dan sejumlah besar pernyataan dapat menunjukkan sebaliknya. (Ref. "Clean Code: A Handbook of Agile Software Craftmanship" hal. 132, oleh Robert Martin).

— Penjaga penjara
sumber

Mengapa Anda percaya "satu fitur" umumnya sama dengan "satu menegaskan"? Tampaknya Anda ingin menegaskan bahwa sistemnya dalam keadaan seperti yang Anda harapkan, yang dapat berupa sejumlah penegasan. Tapi saya ngelantur karena pertanyaannya adalah tentang penamaan, bukan bagaimana menulis tes integrasi.

— Jeremy Heiler

@Andrew, saya tidak mengatakan itu adalah aturan yang sulit, tetapi menonton sejumlah menegaskan dapat membantu dengan pedoman menguji konsep fitur tidak harus satu per metode. Menjaga mereka agak terbatas dalam lingkup membantu mengidentifikasi di mana masalahnya ketika mereka gagal. Tetapi saya akan memberi Anda bahwa tidak baik untuk mengatakan satu pernyataan, dan saya akan mengeditnya, terima kasih.

— Turnkey

1

Jadi masalahnya adalah nama fungsional yang tepat terlalu panjang untuk nama metode? Saya tahu canggung untuk mulai menulis metode pengujian dengan nama seperti registerAndValidateUnderageUniversityDriverWithCoverageSetA_test()dan mungkin pernah melanggar aturan kompiler untuk nama metode panjang (PL / SQL hanya memungkinkan hingga 30 karakter - Saya tidak tahu apakah Java dan C # memaksakan batas nama pendek seperti itu, tetapi bahkan jika mereka tidak melakukannya cukup sulit melewati titik tertentu dan nama metode yang sangat panjang mungkin hanya berguna untuk kode yang dihasilkan yang dibaca / dikelola oleh kode lain yang dihasilkan). Anda dapat mencoba memperpendeknya regValUnderageUnivDrvrWCovrgA_test()tetapi itu juga sangat mengerikan untuk dibaca. Salah satu opsi yang saya gunakan yang tidak saya sukai tetapi pilihan terbaik saat itu adalahunderageUnivDrvr_test_01()dan kemudian ada spreadsheet yang memetakan nama metode ke deskripsi yang lebih panjang dari fungsionalitas yang diuji. Jelek, tapi berhasil. Anda juga dapat mendokumentasikan deskripsi tes dalam dokumentasi fungsi dalam file sumber, yang dapat berguna karena Anda dapat membuat dokumentasi tes secara langsung dari kode, alih-alih memetakan bolak-balik antara spreadsheet dan kode.

— FrustratedWithFormsDesigner
sumber