Mocha: this.timeout() gagal saat menggunakan fungsi panah ES6

Ini mengikat fungsi ke konteks pengujian, yang tidak dapat dilakukan saat menggunakan fungsi panah. Dari http://mochajs.org/

Maaf tentang itu!

Terima kasih.

Mengapa begitu banyak "keajaiban" yang pada akhirnya menimbulkan masalah? Mengapa tidak ini?:

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', () => ... );  
});

Tidak ada global, tidak ada sihir bermasalah... tapi hanya JavaScript.

Apa yang Anda usulkan adalah perubahan besar dan sesuatu yang sedang dibahas di https://github.com/mochajs/mocha/issues/1969#issuecomment-160925915 Penulisan ulang mungkin memperkenalkan jenis semantik itu :)

Bagus untuk mengetahui. Terima kasih.

@ibc yah, itu harus

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', (suite) => ... );  
});

tetapi apakah dua argumen suite yang berbeda adalah tipe yang sama? mungkin tidak, jadi Anda memiliki nama variabel yang berbeda untuk mencerminkan tipe yang berbeda seperti itu

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', (test) => ... );  
});

lagi pula, operator panah tidak dapat digunakan dalam fungsi yang mengharapkan konteks.

Saya tidak membayangkan melanggar UI BDD untuk #1969--langsung dari kelelawar--meskipun saya bisa dibujuk. Harapan saya adalah kami mempertahankan API yang ada, dan memperkenalkan paket terpisah yang berisi UI BDD. Mocha akan dikirimkan dengan versi UI BDD yang menggunakan API yang ada, tetapi kemudian kami dapat merilis versi baru dari paket UI BDD menggunakan lambda setelahnya--pengguna dapat memilih apakah akan secara eksplisit meningkatkan ke paket itu atau tidak.

Mungkin sintaks ES6 alternatif untuk pembungkus describe atau suite dapat menyelesaikan masalah ini:

describe({ feature: 'create stuff' , do () {
    it('abc', () => {
    }); 
}})

Ini setidaknya akan memungkinkan pengikatan di tingkat suite.

Ada pembaruan tentang ini? aku punya ini

mocha = require('mocha');

mocha.describe('test', (suite) => {

suite.timeout(500);

suite.it('test', (done)=>
          )
    }
)

Dan mendapatkan TypeError: Tidak dapat membaca properti 'batas waktu' dari undefined

@mroien ini bukan bug Mocha. sintaks panah bukan pengganti 1:1 untuk function . silakan baca tentang batasannya

Apakah ada yang datang dari ini? Saya suka solusi yang diusulkan, jika hanya karena kecintaan saya pada fungsi panah dan keengganan untuk 'ini' ketika tidak diperlukan

Karena batas waktu hanya relevan dengan done , mengapa tidak melampirkan fungsi batas waktu saja ke fungsi yang sudah selesai.

it('makes sense', done => {
    done.timeout(100);
});

@nomilous ini masih tidak berfungsi. Saya punya masalah serupa. Apa yang berhasil untuk kasus saya adalah memanggil setTimeout di dalam blok it . misalnya

it('description', done => {
     const func = () => {
          // assertions
     };
     setTimeout(func, 10000);
});

@nomilous sinkron atau kasus yang mengembalikan janji juga dapat memiliki batas waktu.

@andela-engmkwalusimbi ini seharusnya tidak berfungsi. Seperti yang ditulis @boneskull :

@mroien ini bukan bug Mocha. sintaks panah bukan pengganti 1:1 untuk fungsi. silakan baca tentang batasannya

Untuk semua orang yang masih bertanya-tanya tentang ini, pastikan Anda memahami apa arti fungsi panah, lalu kembali ke sini dan baca terus (ada banyak sumber di luar sana yang dapat menjelaskan ini jauh lebih baik daripada yang saya bisa).

Satu-satunya cara fungsi panah ini akan bekerja dalam kasus ini adalah jika kita mengubah bdd API untuk meneruskan objek context ke setiap callback Runnable (pengait, pengujian), alih-alih memanfaatkan this . Itu bukan ide yang buruk , tapi ini adalah gempa bumi perubahan yang menghancurkan, jadi tidak akan pernah terjadi. Alih-alih ini:

it('should do something', function (done) {
  this.timeout(9000);
  // stuff
  done();
});

itu akan terlihat seperti ini:

it('should do something', (context, done) => {
  context.timeout(9000);
  done();
});

Itu akan merusak setiap tes Mocha async yang ada, terlepas dari apakah itu kompatibel dengan versi sebelumnya:

it('should do something', function (context, done) {
  // context is unused, but 'done' is now the second parameter
  this.timeout(9000);
  done();
});

Kami dapat memberikan implementasi bdd alternatif yang melakukan ini, namun--itu tidak akan menjadi default.

Itu tentang penjelasan paling menyeluruh yang saya miliki tentang "di mana masalah ini". :senyum:

Mungkin bisa jadi pertimbangan buat versi major selanjutnya? Saya tidak berpikir ini adalah perubahan yang cukup penting untuk membuat implementasi bdd alternatif. Memiliki argumen bernama mungkin membantu pengembangan di masa depan juga dan mungkin membuat cara sederhana untuk menambahkan semacam middleware uji seperti:

it('should do something', function ({ context, done }) { ...

Kami dapat memberikan implementasi bdd alternatif yang melakukan ini, namun--itu tidak akan menjadi default.

@boneskull Antarmuka bdd-es6 baru akan sangat bagus :)

Meskipun saya jatuh cinta dengan fungsi panah yang sangat berguna untuk misalnya fungsi Array seperti .filter(i => i.val) , apa masalahnya dengan menggunakan fungsi normal? Saya pikir cukup berguna untuk mendeskripsikan dan secara global jadi saya tidak perlu memintanya setiap saat. Juga sejak kapan this ajaib, hanya karena Anda tidak mengerti fungsi (panah)? Saya pasti tidak ingin memberikan variabel setiap kali saya dapat mengembalikan janji, jika tidak saya akan beralih ke sesuatu seperti ava sejak lama. Mengenai kesederhanaan moka, saya pikir seharusnya tidak ada perubahan besar pada fungsi normal/panah yang dijelaskan di #1969. Dan tolong jangan beri tahu saya fungsi panah lebih cepat diketik karena editor Anda dapat mengubah satu f menjadi function () {\n\t\n} .

saya tidak jelas, apakah ada solusi untuk batas waktu panggilan before() yang menggunakan fungsi panah?

    before( async function () {
      data = await provider.getData();
      console.log(data);
      this.timeout(30*1000);
    });

Tidak memiliki efek. masih mendapatkan timeout 4 detik di sini. Ini adalah satu-satunya hal yang lambat di test suite saya. Saya dapat menempatkan batas waktu hingga 30-an dalam mocha.opts untuk menyelesaikan masalah, tetapi saya tidak benar-benar membutuhkan semua tes untuk batas waktu setelah 30-an hanya satu panggilan api ketika 4s baik-baik saja untuk 99% dari mereka.

Inilah cara saya menyelesaikannya sementara (perhatikan bahwa describe() menggunakan function alih-alih sintaks panah gemuk:

describe('Search API', function () {
    this.timeout(30*1000);

    context('search', () => {
        let data;

        before( async () => {
          data = await provider.getSearch();
        });

        it('returns results', () => {
          expect(data).to.exist;
          expect(data.results).to.be.instanceOf(Array);
          expect(data.results.length).to.be.above(0);
        });
    })
});

@chovy Anda mengatur batas waktu setelah batas waktu terjadi di await provider.getData() .
Coba gunakan ini sebagai gantinya:

before(async function () {
  this.timeout(30*1000); // set timeout first, then run the function
  data = await provider.getData();
  console.log(data);
});

saya tidak jelas, apakah ada solusi untuk timeout panggilan before() yang menggunakan fungsi panah?

Untuk memperjelas hal ini: saat ini tidak ada cara untuk memanggil timeout Mocha menggunakan fungsi panah. Setiap diskusi alternatif (betapapun bermanfaatnya) adalah diskusi tentang kemungkinan antarmuka baru (atau setidaknya dimodifikasi).

Sesuatu yang ada dalam pikiran saya untuk sementara waktu dapat dilakukan:

it('...', (done) => {
  ...
  done()
})

dan

it('...', (t) => {
  t.timeout(500)
  t.tag('integration', 'api')
  ...
  t.done()
})

menggunakan antarmuka default yang sama.

Mendukung keduanya dalam antarmuka default yang sama, mari kita mulai menggunakan fungsi panah dalam basis kode yang ada. Patut ditunjukkan bahwa sintaks (done) ditemukan di banyak tutorial online akan tetap berfungsi, tanpa flag atau apa pun.

Jadi dalam implementasi ini, Anda mendapatkan sebagai parameter fungsi done tradisional, tetapi dengan fungsi utilitas ditambahkan sebagai properti dari objek fungsi done itu.

menggunakan this.timeout() menyebabkan waktu yang telah berlalu menghilang dalam laporan.

@dasilvacontin tidak tahu mengapa kami tidak memikirkan itu sebelumnya. itu ide yang bagus.

@dasilvacontin oh, saya ingat. karena Anda harus memanggilnya. Anda mungkin tidak mau.

Maaf, bisakah Anda menguraikan "harus menyebutnya", @boneskull? Apakah Anda berbicara tentang masalah di mana Mocha akan berpikir bahwa tesnya tidak sinkron?

Pada 29 Jan 2017, pukul 05:54, Christopher Hiller [email protected] menulis:

@dasilvacontin oh, saya ingat. karena Anda harus memanggilnya. Anda mungkin tidak mau.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

Juga, bagaimana Anda mendeklarasikan niat Anda untuk membuat tes async saat menggunakan 't'?

Dalam tape Anda selalu harus memanggil 't.done' ('t.end' di API mereka), atau mengatur jumlah pernyataan yang diharapkan ('t.plan').

Apakah mungkin untuk menambahkan argumen ketiga ke it() dengan opsi? Itu tidak akan merusak API.

it ('accepts lambda', (done)=>{ doWork();  done(); }, {timeout:60000});

@boneskull

Bagaimana jika alih-alih menempatkan konteks terlebih dahulu, itu adalah pilihan kedua?

Alih-alih ini:

it('should do something', function (done) {
  this.timeout(9000);
  // stuff
  done();
});

itu akan terlihat seperti ini:

it('should do something', (done, context) => {
  context.timeout(9000);
  done();
});

it('should do something', function (done, context) {
  // context is unused, but 'done' is now the second parameter
  this.timeout(9000);
  done();
});

Kami dapat memberikan implementasi bdd alternatif yang melakukan ini, namun--itu tidak akan menjadi default.

Itu tentang penjelasan paling menyeluruh yang saya miliki tentang "di mana masalah ini". 😄

atau jika konteksnya harus berupa param . yang ditentukan

it('should do something', function (done, override) {
  // context is unused, but 'done' is now the second parameter
  override.timeout(9000);
  done();
});

Tapi saya juga akan menggunakan antarmuka non-default :)

Kelemahan dari solusi apa pun yang membutuhkan done adalah Anda harus menggunakan done bahkan jika mengembalikan janji akan lebih sederhana. Berbicara sendiri, saya tahu saya lebih suka mengetik function dan return daripada .then(()=>{done()}, done) !

@Flamenco Itu ide yang menarik, meskipun saya mungkin lebih suka memiliki fungsi terakhir (ya, secara teknis lebih "ajaib" seperti itu tetapi, mari kita hadapi itu, cukup mudah untuk memeriksa apakah parameternya adalah suatu fungsi dan itu cukup intuitif untuk digunakan dan itu tidak seperti Mocha dimasukkan ke dalam semacam abstraksi lain yang "ajaib" seperti itu bisa pecah); objek opsi semacam itu juga dapat digunakan untuk memberikan tag dan/atau alasan pengujian yang tertunda, yang keduanya merupakan fitur yang diminta (menemukannya di kotak pencarian daftar masalah GitHub/PR dibiarkan sebagai latihan bagi pembaca) yang saya gunakan Saya akan mengaku bersimpati (bahkan jika mungkin untuk mengatasi ketidakhadiran mereka, ada keuntungan untuk hal yang nyata daripada solusi).

@ScottFreeCode Saya sangat setuju tentang done Saya juga tidak suka menggunakannya, saya hanya berkomentar mengenai perlunya menempatkan konteks terlebih dahulu vs terakhir dan menggunakan contoh yang disebutkan di atas yang disediakan oleh bonekull.

Saya hanya menyukai opsi untuk meneruskan konteks atau mengatur beberapa sakelar pada moka untuk eksekusi es6.

Sementara itu saya hanya membungkus beberapa deskripsi pengujian yang memerlukan perbedaan waktu habis dalam panggilan function() yang tampak seperti derpy.

Saya menemukan solusi untuk kasus penggunaan di mana janji dikembalikan ke moka dari fungsi panah yang membutuhkan batas waktu khusus, yang ingin saya bagikan jika orang lain menganggapnya berguna.

Dengan menambahkan fungsi when berikut yang didefinisikan di bawah ini dalam deklarasi pengujian seperti ini: it('does something', when(() => someFunctionReturningAPromise, customTimeout)) batas waktu moka dapat diatur tanpa melepaskan fungsi panah.

Demikian pula, dan karena kami hanya bekerja dengan janji, kami dapat mengambil kembali parameter pertama untuk pengujian dan lulus dalam konteks alih-alih panggilan balik yang dilakukan: it('can access the mocha test context', when(testContext => someFunctionThatNeedsContext(testContext))

const when = (lambda, timeout) =>
  function() { // return a plain function for mocha to bind this to
    this.timeout(timeout || this.timeout() || 1000)
    return lambda(this)
  }

Beberapa kasus uji untuk diilustrasikan:

const delay = timeout =>
  new Promise((resolve, reject) => setTimeout(resolve, timeout))

const deject = timeout => // similar to above, but a delayed reject
  new Promise((resolve, reject) => setTimeout(reject, timeout))

describe('mocha testing', () => {
  context('with only arrow functions', () => {
    context('tests that do not time out', () => {
      it('passes fast', when(() => delay(10), 100))
      it('does not usually time out', when(() => delay(2000), 2010))
    })
    context('tests that will time out', () => { // these should fail if the 'when' function works properly
      it('times out fast', when(() => delay(1000), 10)) // will fail in 10ms
      it('times out', when(() => delay(1000), 1000)) // will fail in about 1000ms
    })
    context('tests that will reject', () => { // this shows the when function works as expected when a test rejects
      it('fails fast', when(() => deject(10), 100))
    })
  })
})

@astitt-ripple ya, atau Anda cukup menulis function () {} ... Wtf?

Oke luca, sakit gigit. :-)

Bedanya dengan fungsi panah, pengembaliannya bisa dilewati. dalam sebuah
pengaturan tipe es6, ini sudah bisa menjadi pola umum untuk janji 'lalu'
rantai.

Dengan blok fungsi, seperti yang Anda sarankan, dan sejauh yang saya tahu, pengembalian untuk
janji harus eksplisit. Minimal untuk fungsi tes berbasis janji
{... } salah, tes harus selalu mengembalikan janjinya, jadi minimal
sepele yang valid sebenarnya: fungsi { return ... }. Jika tidak,
tes mengembalikan tidak terdefinisi ke moka dan bukan janji yang dikirim ...
penulis tes memiliki waktu yang buruk.

Jika sebagian besar kode dalam basis kode sudah berfungsi panah dari janji
dan/atau gaya pemrograman fungsional, menambahkan pengembalian fungsi dapat terlihat
tidak konsisten. Formulir 'kapan' yang disarankan tersedia sebagai gantinya bagi mereka yang
lebih suka panah dan gaya yang lebih fungsional daripada fungsi tradisional
panggilan balik atau gaya pengembalian fungsi. Lebih ringkas, dan cocok dengan
jelaskan konteksnya dsl kita semua setuju kita suka menulis tes, dengan mempertimbangkan
akun janji abstraksi pemrograman async menangani javascript begitu
dengan baik. Juga lebih pendek dari function+return, bahkan tanpa sobat kita yang keriting:
ketika (() => ...).

Mungkin itu bukan gaya yang disukai dari proyek ini, saya mengerti itu, dan
saya tidak mengusulkannya sebagai perubahan pada proyek. Mungkin genap
tercela seperti yang tersirat dari wtf Anda. Tidak apa-apa. Mocha harus bekerja dengan
js ramah pra-fp. Kompatibilitas mundur adalah perhatian kelas satu. Itu
juga masuk akal.

Ini adalah utas yang panjang dan menemui jalan buntu, dan ini adalah salah satu jalan keluarnya. Satu bagus
hal tentang javascript adalah tidak harus ada satu cara atau satu gaya untuk
menyelesaikan sesuatu. Kita tidak harus menyetujui gaya sama sekali. Secara fungsional
berbicara, posting saya sebelumnya memberi orang cara untuk menggunakan panah dan janji
secara konsisten dan dengan dsl uji, tanpa melepaskan akses ke mocha
konteks, dengan cara ramah pemrograman yang bersih dan fungsional yang belum
telah disarankan sebelumnya.

Terima kasih.

Jika sebagian besar kode dalam basis kode sudah ... gaya pemrograman fungsional ...

...kemudian menggunakan this.mutatingMethod(currentConfiguration) untuk mengatur perilaku, terutama fungsi (atau lebih tepatnya subrutin) yang sudah dijalankan, jauh lebih tidak konsisten daripada harus menulis return (yang hanya sintaks) , dan penampilan yang tidak konsisten akan membuat kenyataan itu lebih jelas daripada benar-benar memperkenalkan ketidakkonsistenan.

(Jangan salah paham, saya cukup senang dengan meningkatnya popularitas ide pemrograman fungsional di JS; tetapi sintaks function / return vs => adalah sebenarnya tidak penting untuk pemrograman fungsional, hanya masalah apa yang terlihat lebih bersih dalam paradigma itu, sedangkan konsep lain seperti kemurnian dan deklaratif vs imperatif sebenarnya penting. Akan lebih baik untuk memiliki pelari uji yang, sebaliknya, lebih fungsional dalam perilakunya / semantik , di mana beralih ke fungsi panah mungkin akan sepele ...)

Saya setuju dengan Anda bahwa this.timeout adalah mutasi dan keluar dari paradigma pemrograman fungsional. Tentu saja itu sama sekali tidak konsisten. Saat ini, apakah ada cara lain untuk mendeklarasikan batas waktu khusus per pengujian selain this.timeout?

Dalam implementasi mocha saat ini, tampaknya perlu untuk melarikan diri kembali ke paradigma imperatif/mutasi, atau menyerah pengaturan per batas waktu pengujian. Satu atau yang lain.

Dalam abstraksi when , batas waktu adalah parameter kedua kapan, memungkinkan gaya fungsional untuk tetap berada di level pengujian. Ini menyembunyikan pelarian yang tak terhindarkan dari mode FP kembali ke pemrograman imperatif, tetapi melakukannya di satu tempat. Selain itu, ini memberikan akses fungsi panah ke konteks moka, yang tidak mungkin dilakukan tanpa melanggar konvensi parameter fungsi pengujian. Jadi ini berpotensi memecahkan beberapa masalah untuk beberapa pengguna proyek ini (dilihat dari riwayat masalah ini) untuk sementara sampai seseorang mengeksplorasi ide test-runner Anda.

Juga tolong jangan salah paham. Saya tidak berpikir pemrograman fungsional akan pernah atau harus sepenuhnya menggantikan pemrograman imperatif/mutasi yang diturunkan dari mesin turing. Misalnya dalam hampir setiap kasus, dalam runtime JS kode, fungsional atau tidak, pada akhirnya ditafsirkan oleh program yang ditulis dengan gaya imperatif yang lebih tradisional (mungkin c++, tetapi tidak harus), berjalan pada sistem operasi yang juga ditulis di sekitar mutasi. dan ide-ide imperatif (mungkin C). Memori adalah sumber daya tetap, struktur data yang tidak dapat diubah adalah kebohongan yang dikatakan runtime kepada kita. Model yang sangat penting itu adalah default dalam komputasi, dan akan tetap ada. Tapi itu tidak berarti pemrograman fungsional tidak bisa hidup berdampingan di atasnya. Dan jika demikian, tidak dapat dihindari bahwa kode FP harus diturunkan ke model yang mendasarinya dari waktu ke waktu. Saya tidak berpikir itu berarti kita mengangkat tangan dan mengatakan semua sintaksnya, dan mari kita gunakan fungsi/pengembalian.

Sebenarnya kita bisa melakukan pemrograman fungsional dalam C dengan toleransi tertentu untuk detail, seperti halnya benar bahwa Anda dapat melakukan pemrograman fungsional dengan fungsi/pengembalian alih-alih => fungsi. Hanya saja, jangan lupa untuk mengembalikan janjimu. FP di C membutuhkan sedikit lebih banyak pengetikan, yang bagaimanapun, hanyalah sintaksis belaka.../s

Pada akhirnya, fungsi panah membawa kita secara bertahap lebih dekat ke cara yang bisa diterapkan dan praktis untuk bekerja dalam model kalkulus lambda, dalam bahasa populer. Menghapus karakter tambahan itu membuat perbedaan kecil tapi penting. Masih banyak keterbatasan praktis, tetapi banyak di antaranya yang dapat dipecahkan, salah satunya adalah subjek yang ada.

Omong-omong. Saya akan menggunakan fungsi pembantu yang saya sarankan, dan yang lain juga bebas menggunakannya sekarang. Saya menantikan solusi uji coba Anda, tetapi sementara itu, saya tidak tahu apakah akan sangat produktif untuk terus mencoba meyakinkan satu sama lain tentang pendapat kami sendiri tentang sintaks apa yang penting atau tidak, seolah-olah ada adalah salah satu cara. Saya suka panah, dan Anda suka fungsi. Saya belum melihat argumen meyakinkan yang mengubah pandangan saya. Saya terbuka untuk satu, tetapi sebaiknya lebih dipikirkan daripada spontan seperti: "gunakan saja fungsi, wtf" atau "Anda masih dapat melakukan fp dengan _sintaks_ yang lebih verbose".

Selesaikan masalah dengan cara lain, dan tidak ada yang perlu menggunakan when . kata Nuf. :-)

Saya tidak berpikir itu berarti kita mengangkat tangan dan mengatakan semua sintaksnya, dan mari kita gunakan fungsi/pengembalian.

Saya suka panah, dan Anda suka fungsi.

...sebaiknya lebih dipikirkan daripada spontan seperti: ... "Anda masih bisa melakukan fp dengan sintaks yang lebih verbose".

Itu kebalikan dari apa yang saya katakan, meskipun - saya akan fakta bahwa fungsi panah yang masih menggunakan this tidak akan menjadi FP di tempat pertama, mereka akan menjadi OO dengan fungsi panah ( kebalikan dari FP dengan fungsi JS tradisional). Dengan kata lain, jauh dari sekedar sintaks yang berbeda, masalah sebenarnya adalah bahwa ada ketidakcocokan paradigma yang lebih dalam dari sekedar ketidakcocokan sintaks (seperti yang dirancang Mocha saat ini).

Saya cukup yakin itu mungkin untuk membangun antarmuka alternatif di atas Mocha untuk mengganti this bersama-sama dengan parameter. Saya hanya ingin memperjelas bahwa jika Anda ingin menggunakan FP dalam tes menulis, Anda harus melakukan lebih dari sekadar menemukan cara untuk melewatkan this Mocha ke fungsi panah. Saya sangat banyak untuk naik ke semacam tantangan, namun. ;^)

(Ada juga beberapa perilaku lain dari Mocha yang stateful, global, atau -- lebih buruk -- keduanya, tapi saat ini saya tidak punya waktu untuk menemukan cara singkat untuk membuat daftarnya. Jika Anda pernah melihat masalah seputar menjalankan Mocha lebih dari sekali, itu contohnya.)

Saat ini, apakah ada cara lain untuk mendeklarasikan batas waktu khusus per pengujian selain this.timeout?

Sayangnya, saya cukup yakin tidak ada; dari atas kepala saya saran untuk menerima parameter tambahan ke it yang akan menjadi peta nilai kunci (sebagai objek JS) pengaturan konfigurasi terdengar seperti solusi masa depan yang layak di Mocha, jika ada yang mau coba terapkan.

Saat ini, apakah ada cara lain untuk mendeklarasikan batas waktu khusus per pengujian selain this.timeout?

Sayangnya, saya cukup yakin tidak ada;

Terima kasih telah mengonfirmasi detail ini. Ini memperkuat poin yang saya buat.

dari atas kepala saya saran untuk menerima parameter tambahan yang akan menjadi peta nilai kunci (sebagai objek JS) pengaturan konfigurasi terdengar seperti solusi masa depan yang layak di Mocha, jika ada yang ingin mencoba mengimplementasikannya.

+1 untuk solusi yang lebih umum.

Dari apa yang saya tahu, sepertinya masih bisa melewati satu parameter. Gabungkan this dengan done callback (jadi this menjadi fungsi). Kemudian minta mocha menjalankan setiap tes yang dibungkus dengan janji (baik, dua sebenarnya, satu untuk menangani batas waktu, dan satu untuk benar-benar menjalankan tes), terlepas dari jumlah parameter (berangkat dari cara kerjanya hari ini). Itu kemudian dapat memeriksa bahwa hasil dari fungsi itu adalah janji atau tidak. Jika tidak, panggil done setelah fungsi sinkron kembali untuk menyelesaikan pengujian. Jika hasil dari fungsi tersebut adalah sebuah janji, maka tunggu hingga fungsi tersebut diselesaikan (atau ditolak). Jika batas waktu terjadi, hentikan tes (sama seperti sebelumnya). Dalam kasus di mana tes berhasil memanggil done dan juga mengembalikan janji. Entah dilakukan dipanggil sebelum resolusi, dalam hal ini moka harus menunggu janji dan kemudian gagal tes karena memiliki urutan penyelesaian yang ambigu. Atau done dipanggil beberapa saat setelah resolusi, dalam hal ini entah bagaimana tes harus gagal secara surut -- atau masalah menandakan beberapa cara lain yang masuk akal. Maaf itu banyak goresan lebar, tapi itu pemahaman orang luar saya tentang apa yang coba dilakukan moka dan kebiasaan yang dihadapinya. Pertimbangan lain apa yang mungkin mencegah ini menjadi solusi yang bisa diterapkan?

jika Anda ingin melakukan FP dalam tes menulis, Anda harus melakukan lebih dari sekadar menemukan cara untuk meneruskan Mocha's this ke fungsi panah

sepakat. ada perubahan yang pasti dalam beralih ke model komputasi yang berbeda, dan selain itu javascript adalah ekosistem yang kompleks dengan banyak hal yang perlu dipertimbangkan. Dalam kasus penggunaan khusus saya, namun mengatur batas waktu dari waktu ke waktu (seperti menjadi lebih akurat berdasarkan beberapa perhitungan daripada nilai default tetap), adalah satu-satunya masalah nyata yang saya temui saat menulis tes FP dengan Mocha (sejauh ini paling sedikit). Yang bagus. :+1:

Yang mengatakan, saya ingin tahu apa lagi yang Anda lihat sebagai hambatan yang akan datang yang secara khusus berkaitan dengan Mocha (berlawanan dengan apa yang mungkin berarti tes menulis di FP secara umum).

Itu kebalikan dari apa yang saya katakan, meskipun

Saya minta maaf jika saya salah mengartikan atau salah paham. Untuk sebagian besar dari apa yang saya tulis, saya juga tidak yakin apa yang saya maksudkan, berdasarkan balasan. Sangat disayangkan, karena saya pikir jika kita membahasnya, kita mungkin akan mencapai kesepakatan yang cukup dekat tentang seperti apa FP _seharusnya_ dalam _teori_. Namun di sini tampaknya, kami tidak setuju seperti apa pengurangan yang bisa diterapkan pada _practice_ mungkin terlihat seperti dalam rilis Mocha yang tersedia saat ini, setidaknya untuk beberapa pengguna/kasus penggunaan. Jadi saya tidak yakin persis apa masalah utama dengan fungsi add-on yang saya usulkan, dari pihak Anda.

(Dikutip dan dijawab secara berurutan, tetapi bisa dibilang hal yang lebih penting adalah nanti daripada sebelumnya.)

Dari apa yang saya tahu, sepertinya masih bisa melewati satu parameter. Gabungkan ini dengan panggilan balik yang dilakukan (jadi ini menjadi fungsi). Lalu... Pertimbangan lain apa yang mungkin mencegah hal ini menjadi solusi yang bisa diterapkan?

Jika kita mematahkan kompatibilitas ke belakang, ada desain yang lebih sederhana yang bisa kita gunakan.

Jika kita menjaga kompatibilitas mundur, kedua tes ini harus lulus dan tidak time out:

it("runs immediately", () => {
  // call functions and assert whatever
})
it("runs asynchronously", doneWithSomeOtherName => {
  setTimeout(() => {
    // call functions and assert whatever
    doneWithSomeOtherName()
  }, 100)
})

Anda dipersilakan untuk mencoba membuat beberapa contoh kode untuk membuktikan sebaliknya (walaupun saya menyarankan untuk berfokus pada saran di akhir komentar ini), tetapi saya cukup yakin tidak ada desain yang dapat melakukan itu dan juga buat tes ini lulus dan bukan waktu habis:

it("looks just like an asynchronous test with a different name for `done`, but never tells Mocha it's done", context => {
  context.configureByMutation("some value")
  // call functions and assert whatever
})

Tapi juga, perhatikan mutasi di sana. Lebih lanjut tentang ini di bawah ini.

Dalam kasus penggunaan khusus saya, namun mengatur batas waktu dari waktu ke waktu (seperti menjadi lebih akurat berdasarkan beberapa perhitungan daripada nilai default tetap), adalah satu-satunya masalah nyata yang saya temui saat menulis tes FP dengan Mocha (sejauh ini paling sedikit). Yang bagus.

:+1:!

Yang mengatakan, saya ingin tahu apa lagi yang Anda lihat sebagai hambatan yang akan datang yang secara khusus berkaitan dengan Mocha (berlawanan dengan apa yang mungkin berarti tes menulis di FP secara umum).

Saya pikir saya mungkin tidak mengomunikasikan hal ini dengan cukup fokus...edly, jadi biarkan saya melihat apakah saya dapat mempersempitnya sedikit lebih jauh. (Juga maaf jika semua ini dianggap antagonis; itu tentu saja tidak dimaksudkan, meskipun saya akui mencoba mengubah pola pikir di sini.) Basis kode Mocha sangat mirip dengan hierarki kelas dan gaya getter dan setter dari "orientasi objek" (dan ada banyak masalah atau masalah potensial yang dimiliki Mocha yang saya yakini akan berubah menjadi keadaannya yang bisa berubah), tetapi itu umumnya tidak memengaruhi kode pengujian Anda jika yang Anda lakukan hanyalah menulis tes dan membiarkan Mocha menjalankannya . Anda dapat melakukan hal-hal aneh dengan konfigurasi mutasi imperatif Mocha:

it("imperatively sets the timeout multiple times", function(done) {
  this.timeout(5000)
  var context = this
  setTimeout(function() {
    context.timeout(1000)
    setTimeout(done, 500)
  }, 4000)
})

...tapi Anda tidak harus melakukannya. Seperti banyak elemen pemrograman secara fungsional dalam bahasa non-fungsional: jangan menyalahgunakan hal-hal penting.

(Ada juga argumen yang dibuat bahwa pengecualian tidak murni, tetapi saya belum yakin bahwa pengecualian yang dilemparkan berdasarkan input - yang hanya dapat dianggap sebagai bentuk lain dari output. Jadi beberapa orang akan mengatakan bahwa menggunakan pernyataan lemparan itu tidak berfungsi, tetapi saya tidak akan mengatasinya pada saat ini.)

(Bagian penting di sini :) Apa yang saya coba dapatkan adalah, kita sedang melihat kemungkinan menambahkan komplikasi ke basis kode yang sudah kompleks, atau membuat perubahan yang tidak kompatibel ke belakang. Kita perlu pembenaran untuk salah satu dari hal-hal itu. Jika pembenarannya adalah "buat tes lebih fungsional", itu bagus (toh dalam buku saya). Desain yang membuat tes lebih fungsional mungkin sepadan dengan masalahnya (tergantung pada seberapa banyak masalah itu). Tetapi jika dengan "membuat tes lebih fungsional" maksud Anda "membuat fungsi panah mengubah sesuatu", yaitu "membuat fungsi panah kurang berfungsi", itu sangat melemahkan kasusnya (jika bukan hanya bertentangan dengan diri sendiri). Lebih lengkap: Saya tidak berpikir bahwa membuat tes terlihat lebih fungsional (sebersih fungsi panah memang terlihat!) sambil mempertahankan sedikit mutasi yang terlibat, betapapun kecilnya untuk memulai, hampir sama menariknya dengan pembenaran yang sebenarnya menyingkirkan sedikit mutasi itu adalah -- setidaknya jika intinya adalah membuat tes lebih fungsional.

Saya mungkin seharusnya tidak terlalu jauh pada garis singgung ini; lihat di bawah tentang solusi. 😸

Jadi saya tidak yakin persis apa masalah utama dengan fungsi add-on yang saya usulkan, dari pihak Anda.

(Juga bagian penting di sini :) Yah, saya suka sedikit di mana dibutuhkan timeout sebagai parameter alih-alih pemanggilan metode, sebenarnya! Jika Anda dapat menemukan cara untuk menggeneralisasikannya ke metode konfigurasi Mocha lainnya (ada banyak dari mereka -- dan beberapa berlaku untuk tes sinkron jika saya ingat dengan benar, maka mengapa kita tidak bisa menambahkan metode yang sama seperti properties pada done dan biarkan orang menulis tes asinkron yang dapat memanggil konfigurasi melalui done , tapi saya ngelantur), maka saya pasti ingin melihatnya. Paling tidak kami mungkin ingin menjadikannya sebagai rekomendasi, dan kami bahkan mungkin dapat mengadopsi implementasi ke it ketika melewati parameter ketiga (atau sesuatu seperti itu, mungkin it.configured atau it(...).configured(...) jika kita tidak ingin lebih banyak jumlah parameter...) -- yang menurut saya akan menjadi solusi yang kompatibel ke belakang yang menangani masalah mutasi/imperatif yang mendasarinya dan mendapat dukungan fungsi panah "yang benar cara" (apa yang saya perdebatkan seperti itu): karena itu cocok dengan perilaku baru. Saya kira apa yang seharusnya saya katakan, daripada mengejar this dalam solusi, adalah: mari kita perluas bagian parameternya!

Saya bersumpah saya membaca di suatu tempat Anda dapat melakukan sesuatu seperti ini:

describe('a slow thing', () => {
 // test code...
}).timeout(5000);

yang tidak mengubah kontrak parameter ke fungsi yang disediakan. Sekarang saya tidak dapat menemukan referensi untuk hal seperti itu jadi mungkin saya hanya membayangkannya.

@thom-nic ini berhasil! saya kira itu masuk akal karena semua fungsi moka mengembalikan konteksnya

return this;

Ini berfungsi dengan saya saat mengganti bentuk fungsi panah dengan fungsi normal

fungsi() { ..... }

Halo Teman-teman. Saya minta maaf karena menjadi gelap setelah memicu diskusi kembali pada bulan Agustus, saya sudah cukup sibuk dan sebenarnya sebagian besar sudah selesai/pindah dari pekerjaan itu.

Saya menghargai tanggapan terperinci tentang kasus penggunaan yang berbeda dan betapa sulitnya menyatukannya. Itu adalah tampilan paling ringkas dari berbagai pengaturan yang harus didukung oleh moka yang pernah saya baca. Jadi terima kasih atas waktu Anda untuk yang satu itu.

Melihat ke belakang, jelas bahwa saya harus terlalu menekankan untuk mendapatkan akses ke konteks moka ( this ), ketika aspek itu benar-benar lebih merupakan pertimbangan yang nyaman. Saya tidak menyadari betapa mudahnya itu akan menarik perhatian dari apa yang sebenarnya saya coba lakukan: yang bersenang-senang dengan menambahkan ekstensi temporal'ish ( when ) ke test dsl untuk merampingkan satu kali penyesuaian batas waktu (ditambah menghilangkan kesalahan umum untuk gaya pengujian tertentu, yang akan saya jelaskan di bawah). Mengembalikan this hanyalah hal menyenangkan lain yang saya pikirkan untuk ditambahkan, ide utama (maka nama when ) adalah untuk menangani kasus yang membutuhkan waktu tunggu yang berbeda dari biasanya.

Jelas, jika saya ingin mengakses konteks terikat, saya cukup menggunakan function secara langsung seperti yang disarankan banyak orang, daripada mengangkatnya dengan pembungkus. Bukan itu masalahnya. Saya tidak tahu bagaimana hal itu mungkin tampak aneh di hadapannya. Saya berharap mungkin itu akan melengkapi gambar jika saya menunjukkan bagaimana saya menyiapkan beberapa tes yang membawa saya ke jalan ini untuk memulai. Untuk lebih jelasnya, saya tidak mencoba menjual gaya tertentu di sini, gunakan apa yang cocok untuk Anda. Inilah yang berhasil untuk saya.

Oke
Pertama, mulailah dengan asumsi bahwa kami menguji beberapa pengaturan yang pada dasarnya melakukan satu hal, tetapi akan melakukannya untuk berbagai input, jadi kami harus menguji hal ini dalam banyak skenario untuk memastikan outputnya benar. . Namun, karena kode aplikasi yang relevan "melakukan satu hal", prosedur pengujian yang mendasarinya hampir selalu sama. Saya juga tidak ingin menduplikasi/memutasi badan uji secara tidak perlu, karena itu memperlambat seberapa cepat saya dapat menambahkan lebih banyak kasus uji untuk input baru dan akhirnya pemeliharaan menjadi tidak masuk akal.

Jadi alih-alih kami menulis fungsi yang cukup umum untuk memulai kode aplikasi dengan input yang berpotensi didukung, melakukan tindakan pengujian, dan kemudian menegaskan hasilnya... Tambahkan bahwa dalam kasus saya, saya bekerja dengan abstraksi Janji (untuk alasan yang saya akan keluar), jadi fungsi prosedur pengujian umum ini secara alami harus mengembalikan rantai janji itu. Roti dan mentega es6 jenis barang, sejauh ini bagus.

Sekarang tibalah skenario pengujian, karena kami mengemas semuanya ke dalam fungsi prosedur pengujian kami, kasus pengujian secara efektif mendefinisikan input dan menjalankan fungsi.

Jadi mungkin saya menulis banyak tes seperti ini, dan semuanya _tampaknya_ berfungsi:

it('does something', function() {
  testProcedureFunction('something','1')
})

Jika Anda mengikuti dengan cermat, Anda mungkin sudah memperhatikan bahwa contoh ini memiliki bug. Itu hilang return , dan karena testProcedureFunction dibangun di atas janji (pun intended), itu akan selalu berlalu tidak peduli apakah pernyataan di akhir lolos atau gagal. Ini adalah bug, dan terkadang bisa sangat halus untuk dilacak. Sebagai ilustrasi, tergantung pada bagaimana kita menulis testProcedureFunction dan bagaimana aplikasi ditulis, katakanlah ada beberapa kode sinkron di awal, dan yang meledak alih-alih pernyataan akhir pengujian, testcase bahkan mungkin gagal -- menuntun kita untuk berpikir semuanya baik-baik saja.

Tes tentu saja harus benar-benar terlihat seperti ini dengan pengembalian:

it('does something', function() {
  return testProcedureFunction('something','1')
})

Sekarang saya tahu tes ini akan menjadi satu baris dalam banyak kasus. Sebenarnya, setiap kasus akan menjadi satu baris, kecuali jika inputnya sedemikian rupa sehingga diperlukan batas waktu yang lebih besar. Sekarang di antara perbedaan antara fungsi js klasik dan panah, ada aspek tertentu dari fungsi panah yang berguna di sini: satu pernyataan fungsi panah memiliki pengembalian tersirat ketika kurung kurawal dihilangkan. Jika alih-alih menulis function {...} , sebuah tes menggunakan => ... , maka saya dapat dengan mudah memindai kasus-kasus itu untuk panah dan kurangnya kurung kurawal, dan dengan cepat menyimpulkan bahwa mereka tidak dapat memiliki return hilang ini

Seperti:

it('does something', () => testProcedureFunction('something','1'))

Sekarang bagaimana jika salah satu dari kasus ini memakan waktu lebih lama dari yang lain! Kita tentu saja dapat mengatur batas waktu seperti ini:

it('does something slow', function() {
  this.timeout(10000)
  return testProcedureFunction('somethingSlow','2')
})

Atau mungkin seseorang akan membuat kesalahan dan melakukan ini terlebih dahulu (yang tentu saja tidak berhasil):

it('does something slow', () => {
  this.timeout(10000)
  return testProcedureFunction('somethingSlow','2')
})

Tapi sekarang kita kembali ke tempat kita mulai, basis kode memiliki pola yang siap untuk diulang, yang rentan terhadap bug pengembalian yang hilang (baik oleh saya di masa depan, atau orang berikutnya yang menambahkan fitur -- intinya adalah, ini mudah membuat kesalahan, mungkin tidak diperhatikan, dan mungkin sulit dilacak). Fungsi when menyelesaikan ini, dan memungkinkan kita menggunakan panah secara konsisten lagi:

it('does something slow', when(() => testProcedureFunction('somethingSlow','2'), 10000))

(catatan, saya tidak bisa mendapatkan .timeout(5000) saran dot-chaining di atas berfungsi, mungkin karena versi moka yang perlu saya gunakan, saya tidak ingat lagi, akan memberikan itu mencoba!)
(note2, perhatikan bahwa penggunaan when tidak menggunakan trik menaikkan parameter this -- itu benar-benar hanya pemikiran setelahnya).

Mungkin ada linter yang dapat menandai bug pengembalian-untuk-janji yang hilang (atau mungkin lebih realistis, menegakkan pernyataan pengembalian dengan rhs untuk setiap fungsi). Namun itu bukan pilihan pada saat itu, ditambah saya pikir sintaks panah keluar lebih pendek dan saya merasa (secara subyektif/pribadi) lebih mudah untuk dibaca dan digunakan, yang membuat skala bagi saya menjauh dari function .

Jadi di sana Anda memilikinya.

Saya tidak tahu apakah saya akan punya waktu untuk menanggapi lagi dalam waktu dekat, jadi saya harap itu setidaknya informatif dan jelas, dan bahkan mungkin menempatkan beberapa kontroversi seputar keseluruhan "akses ke konteks moka dari panah" ke tempat tidur.

Terakhir, karena saya menemukan function vs => membingungkan untuk waktu yang lama, saya akan menjatuhkan tautan ini jika tidak jelas bagi siapa pun yang dengan santai membaca mengapa panah tidak dapat mengakses this . Itu adalah penjelasan paling jelas tentang fungsi vs panah yang saya temukan, dan itulah yang akhirnya membantu saya memahami perbedaan dengan cukup baik untuk menggunakannya dengan penuh keyakinan.

https://hacks.mozilla.org/2015/06/es6-in-depth-arrow-functions/

@thom-nic Ini berfungsi pada it , tetapi tidak pada describe .

describe('my test suite', () => {

  it('test case 1', () => {
    // ...
  }).timeout('10s');  // Works on `it`. This test case doesn't timeout

  it('test case 2', () => {
    // ...
  });  // This test case timeouts.

}).timeout('10s');  // Doesn't work on `describe`. Tests are already created when runs to here.

@thom-nic , Anda dapat menggunakan bentuk fungsi normal

describe('my test suite', function() {
this.timeout(n);

...
}

Siapa pun yang mengeluh tentang ini tidak mengerti fungsi panah.

Fungsi panah BUKAN hal ES6 mewah baru yang seharusnya menggantikan function () {} klasik. Satu-satunya tujuan fungsi panah adalah ia mewarisi this dari induknya, di mana function () klasik memiliki this .

Ya, bahkan ketika menggunakan sintaks ES6 penuh, Anda harus tetap menggunakan function () jika Anda ingin menggunakan this dalam konteks fungsi yang benar. Anda harus menggunakan function () dan () => di aplikasi ES6 Anda tergantung pada apa yang Anda coba lakukan.

this.timeout() tidak berfungsi dengan it('....', () => { ... }) karena callback mewarisi this dari fungsi describe() induk, di mana this.timeout() tidak masuk akal pada tingkat itu.

Bukankah fungsi lambda juga memungkinkan Anda untuk secara otomatis mengirim satu argumen ke fungsi tersebut tanpa mendeklarasikannya dalam panggilan?

(param) => aFungsi
...kemudian(Fungsi)

function(){} bisa diikat ke 'ini' tetapi ()=> 'terkunci'

Fungsi panah harus menggantikan fungsi tradisional ketika penerima mengharapkan 'ini' yang telah ditentukan sebelumnya dalam konteks yang sama dengan yang memanggilnya, (dan juga mendapat manfaat dari mengetikkan lebih sedikit kode).

Saya akan melangkah lebih jauh dengan mengatakan tidak pernah menggunakan function() kecuali Anda ingin 'ini' menjadi sesuatu selain apa 'ini' saat menjalankannya.

@Flamenco...

Bukankah fungsi lambda juga memungkinkan Anda untuk secara otomatis mengirim satu argumen ke fungsi tersebut tanpa mendeklarasikannya dalam panggilan?

Saya tidak yakin saya mengerti _persis_ bagaimana Anda mengatakannya.
Sejauh "mengirim argumen ke fungsi", panah gemuk berfungsi seperti fungsi biasa dengan satu pengecualian: jika Anda memiliki tepat 1 argumen, maka Anda dapat mengabaikan tanda kurung.

() => console.log("hi"); //zero arguments requires empty parenthesis
a => console.log(a); //you can optionally leave the parenthesis off for 1 argument
(a,b) => console.log(`${a} ${b}`); //2..n arguments requires parenthesis

Apa yang mungkin Anda dapatkan adalah bahwa panah gemuk memungkinkan Anda untuk _mengembalikan_ nilai dengan menghilangkan kurung kurawal dan kata kunci return selama fungsi Anda adalah ekspresi tunggal.
Jadi jika Anda memiliki...

setTimeout(function(a,b) { doSomething(); return calculateSomething(a,b); }, 5000);

...dan Anda ingin mengubahnya menjadi fungsi panah gemuk, Anda tidak akan bisa menghilangkan kurung kurawal dan kata kunci return karena badan fungsi memiliki banyak pernyataan. Anda akan melakukannya seperti ini ...

setTimeout((a,b) => { doSomething(); return calculateSomething(a,b); }, 5000);

Jika, alih-alih Anda mulai dengan...

setTimeout(function(a,b) { return calculateSomething(a,b); }, 5000);

...maka Anda berurusan dengan fungsi yang sangat sederhana sehingga hanya mengembalikan satu ekspresi dan Anda dapat menggunakan...

setTimeout((a,b) => calculateSomething(a,b), 5000);

Itu menjadi jauh lebih mudah dibaca!
Saya menulis lebih banyak tentang ini di codefoster.com/levelup-arrays .

Ada banyak gaya pengkodean yang berbeda dalam JavaScript -- mulai dari OOP hingga FP, dari keamanan jenis yang ketat hingga pengetikan campuran/bebek. Selain itu, ada pola lanjutan di masing-masing gaya tersebut (yaitu injeksi ketergantungan di kamp OOP, currying/monad di kamp FP).

Jika gaya pengkodean Anda lebih dekat ke FP di mana this tidak digunakan dan fungsi panah digunakan untuk mengurangi boilerplate, harus mempertahankan this adalah biaya tambahan untuk pengujian lanjutan (misalnya pengujian berparameter, membuat DSL).

Pengembang berpengalaman mana pun dapat membungkus kerangka pengujian terlebih dahulu agar sesuai dengan gaya pengkodean mereka, tetapi itu berarti kerangka kerja kurang "out-of-the-box". Itu berarti pekerjaan ekstra untuk meningkatkan, mengadopsi plugin, dan memperkenalkan insinyur baru.

Saya suka ide antarmuka bdd alternatif yang tidak menggunakan this dan alih-alih meneruskan apa yang biasanya menjadi objek konteks sebagai parameter ke describe , it dan kait.

Tapi itu tidak begitu mudah untuk diterapkan, IIRC. Akan keren untuk melihat upaya sekalipun.

Saya tahu ini masuk ke lahan efek samping yang serius, tetapi tidak bisakah Anda menangani parameter selesai-atau-konteks seperti ini?

it("runs immediately", () => {
  // call functions and assert whatever
})

it("runs asynchronously", doneOrContext => {
  setTimeout(() => {
    // call functions and assert whatever
    doneOrContext();
  }, 100)
})



md5-b1fe6f00c87a2916712cf6a4df16e142



it("runs immediately using the parameter as a context", doneOrContext => {
  doneOrContext.configureByMutation("some value");
  // As well as changing config, also flags to Mocha that this test is treating the
  // parameter as a context object and is therefore not async.
  // Call functions and assert whatever
})



md5-b1fe6f00c87a2916712cf6a4df16e142



it("runs asynchronously using the parameter as a context", doneOrContext => {
  doneOrContext.configureByMutation("some value");
  doneOrContext.setAsync(); // Flags to Mocha that even though the parameter has been used as
  // a context object, the test is in fact asynchronous.
  setTimeout(() => {
    // call functions and assert whatever
    doneOrContext();
    // or doneOrContext.done()
  }, 100)
})

saya menggunakan skrip di bawah ini tetapi saya mendapatkan kesalahan melebihi batas waktu yang sama.

Skrip saya:

deskripsikan("getBillingDetail", fungsi asinkron (){
this.timeout(55000);
it.only("periksa nama pekerjaan yang diberikan valid", fungsi async (selesai){
this.timeout(55000);
var hasil = menunggu url.getBillingDetail('1225478565647858');
console.log(hasil);
menegaskan.sama(hasil,benar);
});
});

Kesalahan: Batas waktu 55000 ms terlampaui. Untuk pengujian dan pengait asinkron, pastikan "selesai()" dipanggil; jika mengembalikan Janji, pastikan itu terselesaikan.

Jangan meneruskan panggilan balik yang sudah selesai ke fungsi async

Saya telah membuat solusi prototipe yang kompatibel ke belakang. Untuk saat ini modul terpisah, tetapi fungsionalitas dapat dengan mudah digabungkan menjadi mocha benar.

https://github.com/papercuptech/mocha-lambda

cara cepat

require('mocha-lambda')
// now a global '_tst' can be used where 'this' was before

describe('suite', () => {
  beforeEach(() => {
    _tst.answer = 42
  })

  it('provides "this" as "_tst"', function() {
    assert(this === _tst)
  })

  it('works', () => {
    assert(_tst.answer === 42)
    _tst.skip()
  })
})

untuk penamaan eksplisit (dan berfungsi dengan TypeScript)

// if you were previously explicitly importing api (describe, it, etc.) from 'mocha',
// you will have to change to importing from 'mocha-lambda', until (or if) this
// gets merged into mocha proper
import ctx, {describe as d, it as i} from 'mocha-lambda'

d('suite', () => {
  // ctx() is a function that returns "this" as appropriate
  i('works using ctx()', () => {
    ctx().skip()
  })
})

import {Context} from 'mocha'
// ctx() can also rename global
ctx('t')
declare var t: Context
d('suite', () => {
  // ctx() is a function that returns "this" as appropriate
  i('works using renamed global', () => {
    t.skip()
  })
})

@papercuptech Tautan 404 tidak ditemukan.

Woops.. adalah repo pribadi. sekarang publik

Bisa juga npm i mocha-lambda

@aleung @linesh-simplicity, ini digantikan oleh #3485

Terima kasih.

Mengapa begitu banyak "keajaiban" yang pada akhirnya menimbulkan masalah? Mengapa tidak ini?:

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', () => ... );  
});

Tidak ada global, tidak ada sihir bermasalah... tapi hanya JavaScript.

lihat jawaban @thom-nic, bersihkan dan lakukan triknya

Saya bersumpah saya membaca di suatu tempat Anda dapat melakukan sesuatu seperti ini:

describe('a slow thing', () => {
 // test code...
}).timeout(5000);

yang tidak mengubah kontrak parameter ke fungsi yang disediakan. Sekarang saya tidak dapat menemukan referensi untuk hal seperti itu jadi mungkin saya hanya membayangkannya.

@thom-nic solusi bekerja untuk saya, terima kasih!