👉🏿 👩🏾‍🎓 🤹🏻 Menguji proyek Node.js. Bagian 1. Tes anatomi dan jenis tes 👩‍🎤 ☝🏽 👨🏾‍🔧

Penulis bahan, bagian pertama dari terjemahan yang kami terbitkan hari ini, mengatakan bahwa ia, sebagai konsultan independen di Node.js, menganalisis lebih dari 10 proyek setiap tahun. Kliennya, yang dibenarkan, memintanya untuk memberikan perhatian khusus pada pengujian. Beberapa bulan yang lalu, dia mulai membuat catatan tentang teknik pengujian yang berharga dan kesalahan yang dia temui. Hasilnya adalah materi yang berisi tiga lusin rekomendasi untuk pengujian.

Secara khusus, ini akan fokus pada pemilihan jenis tes yang cocok dalam situasi tertentu, pada desain yang tepat, pada penilaian efektivitasnya, dan di mana tepatnya dalam rantai CI / CD Anda perlu menempatkan mereka. Beberapa contoh di sini diilustrasikan menggunakan Jest, beberapa menggunakan Mocha. Materi ini terutama berfokus bukan pada alat, tetapi pada metodologi pengujian.

→ Menguji proyek Node.js. Bagian 2. Tes evaluasi kinerja, integrasi berkelanjutan dan analisis kualitas kode

▍0. Aturan emas: tes harus sangat sederhana dan mudah

Apakah Anda mengenal seseorang - teman, anggota keluarga, pahlawan film, yang selalu dituntut dengan suasana hati yang baik dan selalu siap untuk menawarkan uluran tangan tanpa memerlukan imbalan apa pun? Begitulah tes yang bagus harus dirancang. Mereka harus sederhana, harus bermanfaat dan membangkitkan emosi positif. Ini dapat dicapai dengan pemilihan metode, alat, dan tujuan pengujian yang cermat. Mereka yang penggunaannya membenarkan waktu dan upaya yang dihabiskan untuk menyiapkan dan melakukan tes dan pada saat yang sama memberikan hasil yang baik. Anda hanya perlu menguji apa yang perlu diuji, Anda harus berusaha keras untuk memastikan bahwa tes-tes tersebut sederhana dan fleksibel, dan kadang-kadang Anda dapat menolak beberapa tes, yang berarti mengorbankan keandalan proyek karena kesederhanaan dan kecepatan pengembangannya.

Tes tidak boleh dianggap sebagai kode aplikasi normal. Faktanya adalah bahwa tim tipikal yang terlibat dalam pengembangan proyek, dalam hal apa pun, melakukan segala yang mungkin untuk mempertahankannya dalam kondisi kerja, yaitu, berusaha keras, katakanlah, produk komersial agar berfungsi sesuai harapan penggunanya. Akibatnya, tim semacam itu mungkin tidak terlalu senang bahwa ia harus mendukung "proyek" lain yang rumit, yang diwakili oleh serangkaian tes. Jika tes kode utama tumbuh, menarik lebih banyak perhatian ke diri mereka sendiri dan menjadi penyebab kekhawatiran terus-menerus, maka mengusahakannya akan ditinggalkan atau, mencoba mempertahankan tingkat yang layak, akan memberi mereka begitu banyak waktu dan energi sehingga ini akan memperlambat pekerjaan pada proyek utama.

Oleh karena itu, kode uji harus sesederhana mungkin, dengan jumlah dependensi dan level abstraksi minimum. Tes harus terlihat sehingga mereka dapat dipahami secara sekilas. Sebagian besar rekomendasi yang akan kami pertimbangkan di sini muncul dari prinsip ini.

Bagian 1. Anatomi tes

▍1. Rancang tes Anda sehingga laporan memberi tahu Anda apa yang sedang diuji, dalam skenario apa, dan apa yang diharapkan dari tes tersebut

Rekomendasi

Laporan pengujian harus menunjukkan apakah versi aplikasi saat ini memenuhi persyaratannya. Ini harus dilakukan dalam bentuk yang dapat dimengerti oleh mereka yang tidak harus terbiasa dengan kode aplikasi. Ini mungkin penguji, spesialis DevOps yang menyebarkan proyek, atau pengembang sendiri, yang melihat proyek beberapa waktu setelah menulis kodenya. Ini dapat dicapai jika, saat menulis tes, fokus pada persyaratan produk. Dengan pendekatan ini, struktur pengujian dapat dibayangkan terdiri dari tiga bagian:

Apa sebenarnya yang sedang diuji? Misalnya, metode ProductsService.addNewProduct .
Dalam skenario apa dan dalam kondisi apa pengujian dilakukan? Misalnya, reaksi sistem diperiksa dalam situasi di mana harga barang belum melewati metode.
Apa hasil tes yang diharapkan? Misalnya, dalam situasi yang serupa, sistem menolak untuk mengkonfirmasi penambahan produk baru ke dalamnya.

Konsekuensi Penyimpangan dari Rekomendasi

Misalkan sistem tidak dapat digunakan, dan dari laporan pengujian Anda hanya dapat mengetahui bahwa itu tidak lulus tes yang disebut Add product , yang memeriksa penambahan produk tertentu ke dalamnya. Apakah ini akan memberikan informasi tentang kesalahan sebenarnya?

Pendekatan yang benar

Informasi pengujian terdiri dari tiga bagian informasi.

 //1.   describe('Products Service', function() { //2.  describe('Add new product', function() {   // 3. ,       it('When no price is specified, then the product status is pending approval', ()=> {     const newProduct = new ProductService().add(...);     expect(newProduct.status).to.equal('pendingApproval');   }); }); });

Pendekatan yang benar

Laporan pengujian menyerupai dokumen yang berisi pernyataan persyaratan produk.

Begini tampilannya pada level yang berbeda.

Dokumen Persyaratan Produk, Penamaan Tes, Hasil Tes

Dokumen dengan persyaratan produk dapat berupa, pada kenyataannya, dokumen khusus, atau dapat berupa sesuatu seperti email.
Saat memberi nama tes, menjelaskan tujuan pengujian, skenario dan hasil yang diharapkan, Anda harus mematuhi bahasa yang digunakan untuk merumuskan persyaratan produk. Ini akan membantu Anda membandingkan kode uji dan persyaratan produk.
Hasil tes harus jelas bahkan bagi mereka yang tidak terbiasa dengan kode aplikasi atau sudah benar-benar lupa. Ini adalah penguji, spesialis DevOps, pengembang yang kembali bekerja dengan kode beberapa bulan setelah menulisnya.

▍2. Jelaskan apa yang Anda harapkan dari tes dalam bahasa produk: gunakan pernyataan gaya BDD

Rekomendasi

Pengembangan tes dalam gaya deklaratif memungkinkan mereka yang bekerja dengannya langsung memahami esensi mereka. Jika tes ditulis menggunakan pendekatan imperatif, mereka dipenuhi dengan konstruksi kondisional yang sangat menyulitkan pemahaman mereka. Mengikuti prinsip ini, harapan harus dijelaskan dalam bahasa yang dekat dengan bahasa biasa. Gaya BDD deklaratif menggunakan expect atau should membangun, bukan beberapa kode khusus dari desain mereka sendiri. Jika tidak ada pernyataan yang diperlukan di Chai atau Jest, dan ternyata pernyataan seperti itu sering diperlukan, pertimbangkan untuk menambahkan "cek" baru ke Jest atau menulis plugin Anda sendiri untuk Chai .

Konsekuensi Penyimpangan dari Rekomendasi

Jika Anda tidak mengikuti rekomendasi yang dijelaskan di atas, itu akan berakhir dengan fakta bahwa anggota tim pengembangan akan menulis lebih sedikit tes dan melewati pemeriksaan yang mengganggu menggunakan metode .skip() .

Pendekatan yang salah

Pembaca tes ini harus meninjau sepenuhnya kode imperatif yang agak panjang hanya untuk memahami apa sebenarnya yang diuji dalam tes.

 it("When asking for an admin, ensure only ordered admins in results" , ()={   //,       — "admin1"  "admin2",   "user1"   const allAdmins = getUsers({adminOnly:true});   const admin1Found, adming2Found = false;   allAdmins.forEach(aSingleUser => {       if(aSingleUser === "user1"){           assert.notEqual(aSingleUser, "user1", "A user was found and not admin");       }       if(aSingleUser==="admin1"){           admin1Found = true;       }       if(aSingleUser==="admin2"){           admin2Found = true;       }   });   if(!admin1Found || !admin2Found ){       throw new Error("Not all admins were returned");   } });

Pendekatan yang benar

Anda dapat benar-benar memahami tes ini sekilas.

 it("When asking for an admin, ensure only ordered admins in results" , ()={   //,        const allAdmins = getUsers({adminOnly:true});     expect(allAdmins).to.include.ordered.members(["admin1" , "admin2"]) .but.not.include.ordered.members(["user1"]); });

▍3. Lakukan uji kode linting menggunakan plugin khusus

Rekomendasi

Ada satu set plug-in untuk ESLint yang dirancang khusus untuk menganalisis kode uji dan untuk menemukan masalah dalam kode tersebut. Misalnya, plug-in eslint-plugin-mocha akan memberikan peringatan jika tes ditulis di tingkat global (dan bukan turunan dari describe() ), atau jika tes ternyata dilewati , yang dapat memberikan harapan palsu bahwa semua tes ternyata lulus. Plugin eslint-plugin-jest bekerja dengan cara yang sama, misalnya, peringatan tentang tes yang tidak memiliki pernyataan, yaitu, tentang yang tidak memeriksa apa pun.

Konsekuensi Penyimpangan dari Rekomendasi

Pengembang akan senang melihat bahwa kode tersebut 90% tercakup dalam tes dan 100% dari tes berhasil lulus. Namun, itu akan tetap dalam kondisi ini hanya sampai ternyata banyak tes, pada kenyataannya, tidak memeriksa apa pun, dan beberapa skrip pengujian hanya dilewati. Orang hanya bisa berharap bahwa tidak ada yang akan menyebarkan proyek yang "diuji" dengan cara ini dalam produksi.

Pendekatan yang salah

Skenario pengujian penuh dengan kesalahan, yang, untungnya, dapat dideteksi menggunakan linter.

 describe("Too short description", () => { const userToken = userService.getDefaultToken() // *error:no-setup-in-describe, use hooks (sparingly) instead it("Some description", () => {});//* error: valid-test-description. Must include the word "Should" + at least 5 words }); it.skip("Test name", () => {// *error:no-skipped-tests, error:error:no-global-tests. Put tests only under describe or suite expect("somevalue"); // error:no-assert }); it("Test name", () => {*//error:no-identical-title. Assign unique titles to tests });

▍4. Tetap berpegang pada metode kotak hitam - hanya menguji metode publik

Rekomendasi

Menguji beberapa mekanisme kode internal berarti peningkatan beban yang signifikan pada pengembang dan hampir tidak memberikan manfaat. Jika API tertentu menghasilkan hasil yang benar, apakah layak menghabiskan beberapa jam menguji mekanisme internalnya dan kemudian masih mendukung tes ini, yang sangat mudah pecah, mutakhir? Ketika menguji metode yang tersedia untuk umum, implementasi internal mereka, meskipun secara implisit, juga diverifikasi. Tes semacam itu akan memberikan kesalahan jika muncul masalah dalam sistem, yang menghasilkan penerbitan data yang salah. Pendekatan ini juga disebut "pengujian perilaku." Di sisi lain, menguji mekanisme internal API tertentu (yaitu, menggunakan teknik "kotak putih"), pengembang berfokus pada detail kecil implementasi, dan bukan pada hasil akhir dari kode. Tes yang memeriksa seluk-beluk tersebut dapat mulai menghasilkan kesalahan, misalnya, setelah sedikit kode refactoring, meskipun sistem terus menghasilkan hasil yang benar. Akibatnya, pendekatan ini secara signifikan meningkatkan beban pada programmer yang terkait dengan dukungan kode uji.

Konsekuensi Penyimpangan dari Rekomendasi

Tes yang mencoba menangkap mekanisme internal sistem tertentu berperilaku seperti anak gembala dari dongeng yang menyebut petani dengan teriakan "Tolong! Serigala! ”Ketika tidak ada serigala di dekatnya. Orang-orang lari ke bantuan hanya untuk mengetahui bahwa mereka telah ditipu. Dan ketika serigala benar-benar muncul, tidak ada yang datang untuk menyelamatkan. Tes tersebut menghasilkan hasil positif palsu, misalnya, dalam kasus-kasus ketika nama beberapa variabel internal berubah. Akibatnya, tidak mengherankan bahwa orang yang melakukan tes ini segera mulai mengabaikan "jeritan" mereka, yang, pada akhirnya, mengarah pada fakta bahwa sekali kesalahan serius yang nyata dapat luput dari perhatian.

Pendekatan yang salah

Tes ini menguji mekanisme internal kelas tanpa alasan khusus untuk pemeriksaan tersebut.

 class ProductService{ //      //     ,      calculateVAT(priceWithoutVAT){   return {finalPrice: priceWithoutVAT * 1.2};   //           } //  getPrice(productId){   const desiredProduct= DB.getProduct(productId);   finalPrice = this.calculateVATAdd(desiredProduct.price).finalPrice; } } it("White-box test: When the internal methods get 0 vat, it return 0 response", async () => {   //       VAT,      .  ,   ,        expect(new ProductService().calculateVATAdd(0).finalPrice).to.equal(0); });

▍5. Pilih objek pencadangan yang sesuai: hindari massa, lebih memilih stub dan mata-mata

Rekomendasi

Penggunaan tes berlipat ganda ketika pengujian adalah kejahatan yang perlu, karena mereka terkait dengan mekanisme internal aplikasi. Tanpa beberapa dari mereka, itu tidak mungkin dilakukan. Berikut adalah materi yang bermanfaat tentang topik ini. Namun, berbagai pendekatan untuk penggunaan benda-benda tersebut tidak dapat disebut setara. Jadi, beberapa dari mereka - rintisan (rintisan) dan mata-mata (mata-mata), ditujukan untuk menguji persyaratan untuk produk, tetapi, dalam bentuk efek samping yang tak terhindarkan, mereka dipaksa untuk sedikit mempengaruhi mekanisme internal produk ini. Mock, di sisi lain, ditujukan untuk menguji mekanisme internal proyek. Oleh karena itu, penggunaannya mengarah pada beban besar yang tidak perlu pada programmer, yang kita bicarakan di atas, menawarkan untuk mematuhi metodologi "kotak hitam" saat menulis tes.

Sebelum menggunakan objek duplikat, tanyakan pada diri sendiri satu pertanyaan sederhana: "Apakah saya menggunakannya untuk menguji fungsionalitas yang dijelaskan, atau bisakah itu dijelaskan dalam persyaratan teknis untuk proyek?". Jika jawaban untuk pertanyaan ini negatif, ini mungkin berarti bahwa Anda akan menguji produk menggunakan pendekatan "kotak putih", yang telah kita bicarakan kekurangannya.

Misalnya, jika Anda ingin mengetahui apakah aplikasi Anda berfungsi dengan benar dalam situasi ketika layanan pembayaran tidak tersedia, Anda dapat menghentikan layanan ini dan membuat aplikasi menerima sesuatu yang menunjukkan bahwa tidak ada jawaban. Ini akan memungkinkan Anda untuk memeriksa reaksi sistem terhadap situasi yang sama, untuk mengetahui apakah sistem tersebut berperilaku dengan benar. Dalam perjalanan tes semacam itu, pemeriksaan dilakukan terhadap perilaku, atau respons, atau hasil aplikasi dalam kondisi tertentu. Dalam situasi ini, Anda dapat menggunakan mata-mata untuk memeriksa apakah, setelah mendeteksi penurunan dalam layanan pembayaran, email tertentu telah dikirim. Ini, sekali lagi, akan menjadi pemeriksaan perilaku sistem dalam situasi tertentu, yang, tentu saja, dicatat dalam persyaratan teknis untuk itu, katakanlah, dalam formulir berikut: "Kirim email ke administrator jika pembayaran tidak lulus". Di sisi lain, jika Anda menggunakan objek tiruan untuk mewakili layanan pembayaran dan memeriksa operasi ketika mengaksesnya dengan transfer apa yang diharapkan kepadanya, maka kita akan berbicara tentang pengujian mekanisme internal yang tidak terkait langsung dengan fungsi aplikasi, dan, cukup mungkin bisa sering berubah.

Konsekuensi Penyimpangan dari Rekomendasi

Dengan refactoring kode apa pun, Anda harus mencari semua moki, refactoring, dan kode mereka. Akibatnya, dukungan pengujian akan berubah menjadi beban berat, menjadikan mereka musuh pengembang, bukan teman-temannya.

Pendekatan yang salah

Contoh ini menunjukkan objek tiruan yang berfokus pada pengujian mekanisme internal aplikasi.

 it("When a valid product is about to be deleted, ensure data access DAL was called once, with the right product and right config", async () => {   //,        const dataAccessMock = sinon.mock(DAL);   // ,           dataAccessMock.expects("deleteProduct").once().withArgs(DBConfig, theProductWeJustAdded, true, false);   new ProductService().deletePrice(theProductWeJustAdded);   mock.verify(); });

Pendekatan yang benar

Mata-mata ditujukan untuk menguji sistem untuk kepatuhan terhadap persyaratan mereka, tetapi, sebagai efek samping, mau tak mau mempengaruhi mekanisme internal sistem.

 it("When a valid product is about to be deleted, ensure an email is sent", async () => {   //,        const spy = sinon.spy(Emailer.prototype, "sendEmail");   new ProductService().deletePrice(theProductWeJustAdded);   //  .       ? ,               (  ) });

▍6. Selama pengujian, gunakan input realistis, tidak terbatas pada sesuatu seperti "foo"

Rekomendasi

Seringkali kesalahan dalam produksi dimanifestasikan dalam kombinasi keadaan yang sangat spesifik dan bahkan mengejutkan. Dan ini berarti bahwa semakin dekat dengan kenyataan data input yang digunakan selama pengujian, semakin tinggi kemungkinan deteksi dini kesalahan. Gunakan untuk menghasilkan data yang menyerupai perpustakaan khusus dan nyata seperti Faker . Sebagai contoh, perpustakaan tersebut menghasilkan nomor telepon acak tetapi realistis, nama pengguna, nomor kartu bank, nama perusahaan, dan bahkan teks "lorem ipsum". Selain itu, pertimbangkan untuk menggunakan data dari lingkungan produksi dalam pengujian. Jika Anda ingin mengambil tes seperti itu ke tingkat yang lebih tinggi, lihat rekomendasi kami berikutnya pada pengujian berbasis properti.

Konsekuensi Penyimpangan dari Rekomendasi

Saat menguji suatu proyek selama pengembangannya, semua pengujian dapat dilewati hanya jika dilakukan dengan menggunakan data yang tidak realistis seperti garis “foo”. Tetapi dalam produksi, sistem akan gagal dalam situasi di mana hacker memberinya sesuatu seperti @3e2ddsf . ##' 1 fdsfds . fds432 AAAA @3e2ddsf . ##' 1 fdsfds . fds432 AAAA @3e2ddsf . ##' 1 fdsfds . fds432 AAAA .

Pendekatan yang salah

Sistem berhasil melewati tes ini hanya karena mereka menggunakan data yang tidak realistis.

 const addProduct = (name, price) =>{ const productNameRegexNoSpace = /^\S*$/;//  if(!productNameRegexNoSpace.test(name))   return false;// , -   ,  .     //  -    return true; }; it("Wrong: When adding new product with valid properties, get successful confirmation", async () => {   // "Foo",    ,    ,    false   const addProductResult = addProduct("Foo", 5);   expect(addProductResult).to.be.true;   // :     - ,     //         });

Pendekatan yang benar

Ini menggunakan data acak mirip dengan data nyata.

 it("Better: When adding new valid product, get successful confirmation", async () => {   const addProductResult = addProduct(faker.commerce.productName(), faker.random.number());   //   : {'Sleek Cotton Computer',  85481}   expect(addProductResult).to.be.true;   //  ,         ,    .   //     ,    ! });

▍ 7. Sistem pengujian menggunakan beberapa kombinasi input menggunakan pengujian berbasis properti

Rekomendasi

Biasanya, tes menggunakan set kecil input data. Bahkan jika mereka menyerupai data nyata (kami membicarakan hal ini di bagian sebelumnya), tes semacam itu hanya mencakup sejumlah kemungkinan kombinasi input dari entitas yang diselidiki. Misalnya, mungkin terlihat seperti ini: (method('', true, 1), method("string" , false" , 0)) . Masalahnya adalah bahwa dalam API produksi, yang disebut dengan lima parameter, ia bisa mendapatkan input ribuan varian berbeda dari kombinasi mereka, salah satunya dapat menyebabkan kegagalan (akan lebih tepat untuk mengingat fuzzing di sini ). Bagaimana jika Anda dapat menulis satu tes yang secara otomatis memeriksa metode tertentu untuk 1000 kombinasi inputnya dan mencari tahu mana yang apakah metode merespons dengan salah? Pengujian berdasarkan verifikasi properti adalah persis apa kita dalam situasi seperti ini berguna. Yakni, dalam perjalanan ini pemeriksaan pengujian modul, menyebutnya dengan semua kemungkinan kombinasi dari input data, yang meningkatkan kemungkinan menemukan beberapa bug. Misalkan kita memiliki metode addNewProduct(id, name, isDiscount) , dan Perpustakaan melakukan pengujian, menyebutnya dengan banyak kombinasi parameter numerik, string, dan tipe logis, misalnya - (1, "iPhone", false) , (2, "Galaxy", true) . Dimungkinkan untuk melakukan pengujian berdasarkan verifikasi properti menggunakan lingkungan eksekusi pengujian yang biasa (Mocha, Jest, dan sebagainya) dan menggunakan perpustakaan khusus seperti js-verifikasi atau testcheck (perpustakaan ini memiliki dokumentasi yang sangat baik).

Konsekuensi Penyimpangan dari Rekomendasi

Pengembang, secara tidak sadar, memilih data pengujian yang hanya mencakup bagian-bagian kode yang berfungsi dengan benar. Sayangnya, ini mengurangi efektivitas pengujian sebagai cara mendeteksi kesalahan.

Pendekatan yang benar

Menguji banyak opsi input menggunakan pustaka mocha-testcheck.

 require('mocha-testcheck').install(); const {expect} = require('chai'); const faker = require('faker'); describe('Product service', () => { describe('Adding new', () => {   //  100         check.it('Add new product with random yet valid properties, always successful',     gen.int, gen.string, (id, name) => {       expect(addNewProduct(id, name).status).to.equal('approved');     }); }) });

▍8. Berusaha keras untuk menguji kode menjadi swasembada, meminimalkan bantuan eksternal dan abstraksi

Rekomendasi

Mungkin sekarang jelas bahwa saya berkomitmen untuk tes yang sangat sederhana. Faktanya adalah bahwa jika tidak tim pengembangan proyek tertentu, pada kenyataannya, harus berurusan dengan proyek lain. Untuk memahami kode-nya, mereka harus menghabiskan waktu yang berharga, yang mereka tidak punya banyak. Ini ditulis dengan sangat baik tentang fenomena ini: “Kode produksi berkualitas tinggi adalah kode yang dipikirkan dengan matang, dan kode uji berkualitas tinggi adalah kode yang sepenuhnya dapat dipahami ... Ketika Anda menulis tes, pikirkan tentang siapa yang akan melihat pesan kesalahan yang ditampilkan olehnya. Orang ini tidak ingin, untuk memahami sebab-sebab kesalahan, untuk membaca kode seluruh rangkaian tes atau kode pohon warisan dari utilitas yang digunakan untuk pengujian. "

Agar pembaca dapat memahami tes tanpa meninggalkan kodenya, meminimalkan penggunaan utilitas, kait, atau mekanisme eksternal saat melakukan tes. Jika untuk melakukan ini, Anda perlu terlalu sering menyalin dan menempel kode, Anda dapat berhenti di satu mekanisme bantu eksternal, yang penggunaannya tidak akan melanggar kelengkapan pengujian. Tetapi, jika jumlah mekanisme semacam itu bertambah, kode uji akan kehilangan kelengkapannya.

Konsekuensi Penyimpangan dari Rekomendasi

, 4 , 2 , ? ! , , .

. ?

 test("When getting orders report, get the existing orders", () => {   const queryObject = QueryHelpers.getQueryObject(config.DBInstanceURL);   const reportConfiguration = ReportHelpers.getReportConfig();//   ?        userHelpers.prepareQueryPermissions(reportConfiguration);//  ?         const result = queryObject.query(reportConfiguration);   assertThatReportIsValid();//  ,           -    expect(result).to.be.an('array').that.does.include({id:1, productd:2, orderStatus:"approved"});   //      ?        })

Pendekatan yang benar

, .

 it("When getting orders report, get the existing orders", () => {   // ,           const orderWeJustAdded = ordersTestHelpers.addRandomNewOrder();   const queryObject = newQueryObject(config.DBInstanceURL, queryOptions.deep, useCache:false);   const result = queryObject.query(config.adminUserToken, reports.orders, pageSize:200);   expect(result).to.be.an('array').that.does.include(orderWeJustAdded); })

▍9. :

Rekomendasi

, , , , . . , ( ) . — , ( , ). — , , , , . , , . — , , , , ( , , , ).

Konsekuensi Penyimpangan dari Rekomendasi

, . . . . , , , .

. , .

 before(() => { //       .   ? - ,  -   json-. await DB.AddSeedDataFromJson('seed.json'); }); it("When updating site name, get successful confirmation", async () => { // ,  ,  "Portal", ,           const siteToUpdate = await SiteService.getSiteByName("Portal"); const updateNameResult = await SiteService.changeName(siteToUpdate, "newName"); expect(updateNameResult).to.be(true); }); it("When querying by site name, get the right site", async () => { // ,  ,  "Portal", ,           const siteToCheck = await SiteService.getSiteByName("Portal"); expect(siteToCheck.name).to.be.equal("Portal"); //!      :[ });

Pendekatan yang benar

, , .

 it("When updating site name, get successful confirmation", async () => { //           const siteUnderTest = await SiteService.addSite({   name: "siteForUpdateTest" }); const updateNameResult = await SiteService.changeName(siteUnderTest, "newName"); expect(updateNameResult).to.be(true); });

▍10. , . expect

Rekomendasi

, , try-catch-finally catch . , , , .

Chai, expect(method).to.throw . Jest: expect(method).toThrow() . , . , , .

Konsekuensi Penyimpangan dari Rekomendasi

, , , .

, try-catch .

 it("When no product name, it throws error 400", async() => { let errorWeExceptFor = null; try { const result = await addNewProduct({name:'nest'});} catch (error) { expect(error.code).to.equal('InvalidInput'); errorWeExceptFor = error; } expect(errorWeExceptFor).not.to.be.null; //    ,         //  ,     null,       });

Pendekatan yang benar

expect , , .

 it.only("When no product name, it throws error 400", async() => { expect(addNewProduct)).to.eventually.throw(AppError).with.property('code', "InvalidInput"); });

▍11. ,

Rekomendasi

. , (smoke test), -, , . - . , , , #cold , #api , #sanity . . , Mocha -g ( --grep ).

Konsekuensi Penyimpangan dari Rekomendasi

, , , , , , . .

Pendekatan yang benar

#cold-test , . , -, , — .

 //    ( ,    ),     // ,        //   describe('Order service', function() { describe('Add new order #cold-test #sanity', function() {   it('Scenario - no currency was supplied. Expectation - Use the default currency #sanity', function() {     //-    }); }); });

▍12.

Rekomendasi

, Node.js-. , , Node.js .

TDD — , , . , . , , Red-Green-Refactor . , - , , , , , . , . ( — , , ).

Konsekuensi Penyimpangan dari Rekomendasi

— , . .

2.

▍13. ,

Rekomendasi

, , 10 , . , . , . , (, ), , , , ? - ?

, . , 2019 , , TDD, — , . , , , . , IoT-, , , - Kafka RabbitMQ, . - , , , . , , , , ? (, , Alexa) , , .

, ( ). , , , , , , . , , - API — Consumer-Driven Contracts . , , , , . , , , , , . , , .

, TDD . , TDD , . , , , .

Konsekuensi Penyimpangan dari Rekomendasi

— ( ), .

Pendekatan yang benar

. . , , Node.js, .

▍14. ,

Rekomendasi

. — . , , . , , - , , - ? , . , : TDD, — .

«». API, - , (, , , , , ). , , , (, ). , , , , , , .

Konsekuensi Penyimpangan dari Rekomendasi

, , , , 20.

Pendekatan yang benar

supertest , API, Express, .

API, Express

▍15. , API, Consumer-Driven Contracts

Rekomendasi

, , , , . , , - , , , - . «-22» : . , , . , Consumer-Driven Contracts PACT .

. . PACT , ( «»). , , PACT, , , . , , , , .

Konsekuensi Penyimpangan dari Rekomendasi

Pendekatan yang benar

Consumer-Driven Contracts

, , B , . B .

▍16.

Rekomendasi

(middleware) - , , - , Express-. . , , . , , JS- {req,res} . , «» (, Sinon ) , {req,res} . , , , . node-mock-http , , , . , , HTTP-, -.

Konsekuensi Penyimpangan dari Rekomendasi

Express .

Pendekatan yang benar

Express-.

 // ,     const unitUnderTest = require('./middleware') const httpMocks = require('node-mocks-http'); //  Jest,     Mocha    describe()  it() test('A request without authentication header, should return http status 403', () => { const request = httpMocks.createRequest({   method: 'GET',   url: '/user/42',   headers: {     authentication: ''   } }); const response = httpMocks.createResponse(); unitUnderTest(request, response); expect(response.statusCode).toBe(403); });

▍17.

Rekomendasi

, , , , , , . , , - . , , , ( , , ), , ( — ) . , : SonarQube ( 2600 GitHub) Code Climate ( 1500 ).

Konsekuensi Penyimpangan dari Rekomendasi

, , . . , .

Pendekatan yang benar

Code Climate.

Code Climate

▍18. , Node.js

Rekomendasi

, , . , , , - , . , - , , , , ? , , ? , API ?

Netflix - . , , , , . , - — Chaos Monkey . , , , . Kubernetes — kube-monkey . , Node.js? , , , V8 1.7 . . node-chaos , -.

Konsekuensi Penyimpangan dari Rekomendasi

, , , .

Pendekatan yang benar

npm- chaos-monkey , Node.js.

chaos-monkey

Ringkasan

, Node.js-. , . .

Pembaca yang budiman! - ?