Learn-json-web-tokens: Menguji API yang menggunakan JWT

Nah, saya punya beberapa saran yang mungkin berhasil:

1. Siapkan klien _test_ di sistem Anda dan hardcode token dalam pengujian. Tetap aktifkan autentikasi.
2. Pastikan otentikasi dimatikan, saat menjalankan tes. Saya kira ada berbagai cara untuk melakukan itu. Misalnya di Hapi Anda dapat
3. Mengejek tumpukan, jadi Anda hanya menguji unit logika pengontrol, tanpa membuat permintaan melalui sistem. Ini mungkin tidak layak dalam beberapa kerangka kerja.

Saya sedang mengerjakan beberapa sistem, di mana kami memilih (1). Tes kemudian terlihat sedikit lebih seperti tes integrasi dan bukan tes unit, karena mereka berjalan melalui tumpukan. Di sisi lain, tidak ada perbedaan antara pengujian dan lingkungan produksi.

Anda dapat mengatur NODE_ENV=test , saat menjalankan tes (parameter fx. -e di lab ), jika Anda ingin menentukan lingkungan dalam kode. Namun, Anda harus menyadari bahwa lingkungan pengujian dan produksi tidak terlalu berbeda, jika tidak, Anda tidak benar-benar menguji lingkungan produksi.

@rhewitt22 kami lebih suka pendekatan yang dijelaskan oleh @walling
(di mana tes lebih mirip dengan tes "integrasi" daripada tes "unit")
untuk _tepatnya_ alasan itu. Semua yang Anda olok -

Kami telah mewarisi (_large_) proyek di mana orang _lupa_ memperbarui tiruan ketika mereka mengubah metode dan sebagai hasilnya tes tidak mencerminkan _realitas_; _ mimpi buruk untuk debug _!

Selalu tanyakan pada diri sendiri: "_( Mengapa ) kita perlu mengejek ini ?_"

Jika Anda mengejek sesuatu karena itu di luar kendali Anda, misalnya layanan pihak ketiga atau perangkat jaringan,
masuk akal. Tetapi jika Anda mengejek tumpukan _sendiri Anda _ Anda harus mempertimbangkan bahwa Anda mungkin terlalu memperumit masalah ...

Petunjuk dalam _question_ Anda adalah dalam istilah " _API _", ini menunjukkan bahwa Anda tidak menguji "unit", melainkan (API) "_ titik akhir _".

Tekan titik akhir dan jika Anda mendapatkan 401, Anda tahu bahwa Anda perlu _mengotentikasi_! (_Kabar Baik! Aplikasi Anda berfungsi seperti yang diharapkan!_)

Berikut adalah _contoh kerja _ dari tes yang melakukan _ persis seperti yang Anda butuhkan _:
https://github.com/dwyl/hapi-auth-jwt2/blob/f17bac65d40b2a9154da84390b874cae4e1de192/test/test.js#L119 -L135

Maka saya akan merekomendasikan Membaca:

• Kapan Harus Mengejek: https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
• Ejekan bukanlah rintisan: http://martinfowler.com/articles/mocksArentStubs.html
• Pengujian layanan mikro: http://martinfowler.com/articles/microservice-testing/
• Kapan saya harus mengejek? http://stackoverflow.com/questions/38181/when-should-i-mock

tl; dr

Jika kode _own_ Anda terlalu rumit dan Anda merasa _perlu_ untuk mengejeknya, _sederhanakan kode Anda terlebih dahulu _!!

Juga, kami menulis Plugin hapi-auth-jwt2 kami sehingga orang lain dapat mengandalkan pengujian kami. Dan merilis contoh yang didukung _linear scalable_ Redis: https://github.com/dwyl/hapi-auth-jwt2-example sehingga orang dapat menyalin-tempel (_tested_) kode! :mengedip:

_Kami_ hanya mengejek saat pengujian kami "_merasa terlalu lambat _" jika tidak, kami _selalu_ melatih tumpukan sebanyak _mungkin_ pada setiap tes lulus (sambil membatasi dependensi hanya pada _esensial_).

Jika elemen fungsionalitas Aplikasi Anda memerlukan autentikasi, mengapa Anda tidak menggunakannya sebagai _kesempatan_ untuk _berlatih_ metode autentikasi/verifikasi Anda? Pada akhirnya, mengetahui bagaimana _performant_ auth Anda akan _baik_ untuk aplikasi Anda karena auth/verify adalah salah satu hambatan terbesar di tumpukan Anda! (yaitu _every_ GET/POST/PUT/DELETE _request_ harus melalui auth/verify sehingga tidak perlu lebih dari beberapa milidetik ... lebih dari itu dan aplikasi Anda _tidak akan menskala_!)

Ingat : Jangan _mengasumsikan apa pun _ dan mengambil keputusan sendiri tentang bagaimana masuk akal untuk menguji aplikasi Anda. Jika ada "cara yang benar" untuk melakukan pengujian, semua universitas akan mengajarkannya ... tidak ada. "Cara terbaik" adalah pendekatan "_pragmatic_"; lakukan apa yang masuk akal untuk proyek _your_.

Semoga membantu. jika tidak, beri tahu kami di mana Anda terjebak! :+1:

Terima kasih semuanya! Ini sangat membantu. Berdasarkan saran Anda, saya pikir pengaturan ini cocok untuk pengujian integrasi -- Saya pasti ingin tahu apakah bagian ini bekerja bersama.

Saya hanya menggunakan oAuth sebagai metode otentikasi saya (tanpa nama pengguna/kata sandi). Saya tertarik untuk mempelajari lebih lanjut tentang cara membuat klien uji. Saya tahu bahwa saya tidak ingin melalui seluruh alur oAuth, tetapi ketika Anda menyarankan hardcode sebuah token yang dapat saya gunakan dalam pengujian saya. Bisakah Anda merekomendasikan sumber daya apa pun yang dapat membantu saya memahami pembuatan klien uji?

Jika itu membantu proyek saya saat ini menggunakan SailsJS v11.0. Saya memiliki file pengujian bootstrap yang memulai server saya dan membuat/mengisi database dalam memori dengan perlengkapan. Mungkinkah itu tempat yang tepat untuk membuat klien uji?

Sekali lagi terima kasih -- sungguh luar biasa menemukan orang-orang yang mau berbagi pengetahuan mereka.

@rhewitt22 , baik, dalam kasus saya, klien uji semudah membuat token JWT yang tidak kedaluwarsa yang ditandatangani dengan payload dan kunci rahasia yang benar. Mungkin itu membantu.

Di OAuth, saya pikir itu tergantung pada aliran otentikasi. Mungkin Anda bahkan dapat membuat token akses akhir dengan izin tertentu dan itu tidak kedaluwarsa, sehingga Anda tidak harus melalui alur setiap saat.

Waspadalah terhadap masalah keamanan tentang hardcoding token yang tidak kedaluwarsa dalam pengujian Anda, jika token itu juga memberikan banyak izin dalam sistem produksi. Maka penyerang potensial hanya membutuhkan token ini untuk mendapatkan akses. Anda mungkin menginginkan beberapa cara untuk memberikan akses ke klien tertentu, dan saat menjalankan pengujian, Anda dapat memberikan akses ke klien atau token pengujian Anda. Saya harap semuanya masuk akal.

@walling

Terima kasih atas sarannya!

Saya baru saja melanjutkan dan membuat pengguna palsu, melewatkan aliran oAuth, dalam pengujian saya dan memberi mereka JWT yang sama (dengan kedaluwarsa) yang saya gunakan dalam produksi. Semua tes saya lulus, dan saya kemping yang sangat bahagia.

:senyum: :senyum: :senyum:

Saya pikir ketika saya sedang mengerjakan aplikasi saya dan melihat server pengembangan, saya akan memastikan bagian oAuth berfungsi seperti yang diharapkan.