Hello semua, di sini anda pergi ! Mungkin ramai yang tahu tentang kami dari . Bagi mereka yang baru menyertai: kami sedang membangunkan IDE untuk berfungsi dengan API TestMace. Soalan yang paling kerap ditanya apabila membandingkan TestMace dengan produk pesaing ialah "Bagaimanakah anda berbeza daripada Posmen?" Kami memutuskan bahawa sudah tiba masanya untuk memberikan jawapan terperinci kepada soalan ini. Di bawah ini kami telah menggariskan kelebihan kami .
Berpecah kepada nod
Jika anda bekerja dengan Posman, maka anda tahu bahawa antara muka permintaan mengandungi semua fungsi yang diperlukan. Terdapat skrip, ujian, dan, sebenarnya, pertanyaan itu sendiri. Ini menjadikannya lebih mudah untuk pemula, tetapi dalam senario besar pendekatan ini tidak fleksibel. Bagaimana jika anda ingin membuat beberapa pertanyaan dan melakukan pengagregatan padanya? Bagaimana jika anda ingin melaksanakan skrip tanpa permintaan atau beberapa skrip yang dipisahkan secara logik berturut-turut? Lagipun, adalah idea yang baik untuk memisahkan ujian daripada skrip utiliti biasa. Di samping itu, pendekatan "tambah semua fungsi ke dalam satu nod" tidak boleh skala - antara muka dengan cepat menjadi terlebih beban.
TestMace pada mulanya membahagikan semua fungsi kepada pelbagai jenis nod. Adakah anda ingin membuat permintaan? Ia adalah untuk anda nod Adakah anda mahu menulis skrip? Ia adalah untuk anda nod Perlukan ujian? Tolong - nod Oh ya, anda masih boleh menyelesaikan semua ini nod Dan semua ini boleh digabungkan dengan mudah antara satu sama lain. Pendekatan ini bukan sahaja sangat fleksibel, tetapi juga, mengikut prinsip tanggungjawab tunggal, membolehkan anda menggunakan hanya apa yang anda perlukan pada masa ini. Mengapa saya memerlukan skrip dan ujian jika saya hanya ingin membuat permintaan?
Format projek yang boleh dibaca manusia
Terdapat perbezaan konsep antara TestMace dan Postman dalam cara ia disimpan. Dalam Posman, semua permintaan disimpan di suatu tempat dalam storan tempatan. Jika terdapat keperluan untuk berkongsi permintaan antara beberapa pengguna, maka anda perlu menggunakan penyegerakan terbina dalam. Sebenarnya, ini adalah pendekatan yang diterima umum, tetapi bukan tanpa kelemahannya. Bagaimana dengan keselamatan data? Lagipun, dasar sesetengah syarikat mungkin tidak membenarkan menyimpan data dengan pihak ketiga. Walau bagaimanapun, kami fikir TestMace mempunyai sesuatu yang lebih baik untuk ditawarkan! Dan nama penambahbaikan ini ialah "format projek yang boleh dibaca manusia."
Mari kita mulakan dengan fakta bahawa dalam TestMace, pada dasarnya, terdapat entiti "projek". Dan aplikasi itu pada mulanya dibangunkan dengan tujuan untuk menyimpan projek dalam sistem kawalan versi: pokok projek hampir satu-satu diunjurkan pada struktur fail, yaml digunakan sebagai format storan (tanpa kurungan dan koma tambahan), dan perwakilan fail setiap nod diterangkan secara terperinci dalam dokumentasi dengan ulasan. Tetapi dalam kebanyakan kes anda tidak akan melihat di sana - semua nama medan mempunyai nama logik.
Apa yang diberikan ini kepada pengguna? Ini membolehkan anda menukar aliran kerja pasukan dengan sangat fleksibel, menggunakan pendekatan biasa. Sebagai contoh, pembangun boleh menyimpan projek dalam repositori yang sama dengan bahagian belakang. Di cawangan, selain menukar pangkalan kod itu sendiri, pembangun boleh membetulkan skrip dan ujian pertanyaan sedia ada. Selepas melakukan perubahan pada repositori (git, svn, mercurial - apa sahaja yang anda suka), CI (kegemaran anda, tidak dikenakan oleh sesiapa) melancarkan utiliti konsol kami , dan laporan yang diterima selepas pelaksanaan (contohnya, dalam format junit, yang juga disokong dalam testmace-cli) dihantar ke sistem yang sesuai. Dan isu keselamatan yang disebutkan di atas tidak lagi menjadi masalah.
Seperti yang anda lihat, TestMace tidak mengenakan ekosistem dan paradigmanya. Sebaliknya, ia mudah sesuai dengan proses yang telah ditetapkan.
Pembolehubah Dinamik
TestMace mengikut konsep tanpa kod: jika masalah boleh diselesaikan tanpa menggunakan kod, kami cuba menyediakan peluang ini. Bekerja dengan pembolehubah adalah jenis fungsi yang dalam kebanyakan kes anda boleh lakukan tanpa pengaturcaraan.
Contoh: kami menerima respons daripada pelayan, dan kami ingin menyimpan sebahagian daripada respons ke dalam pembolehubah. Dalam Posman, dalam skrip ujian (yang pelik itu sendiri) kami akan menulis sesuatu seperti:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);Tetapi pada pendapat kami, menulis skrip untuk senario yang begitu mudah dan kerap digunakan kelihatan berlebihan. Oleh itu, dalam TestMace adalah mungkin untuk memberikan sekeping jawapan kepada pembolehubah menggunakan antara muka grafik. Lihat betapa mudahnya:
Dan kini dengan setiap permintaan pembolehubah dinamik ini akan dikemas kini. Tetapi anda boleh membantah, dengan alasan bahawa pendekatan Posman adalah lebih fleksibel dan membolehkan anda bukan sahaja membuat tugasan, tetapi juga melakukan beberapa prapemprosesan. Berikut ialah cara untuk mengubah suai contoh sebelumnya:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));Nah, untuk tujuan ini TestMace mempunyai nod, yang merangkumi senario ini. Untuk menghasilkan semula kes sebelumnya, tetapi telah dilaksanakan oleh TestMace, anda perlu mencipta nod skrip mengikut permintaan dan menggunakan kod berikut sebagai skrip:
const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));Seperti yang anda lihat, komposisi nod juga berfungsi dengan baik di sini. Dan untuk kes mudah seperti yang diterangkan di atas, anda boleh menetapkan ungkapan tersebut ${crypto.MD5($response.data)} pembolehubah yang dibuat melalui GUI!
Mencipta ujian melalui GUI
Posmen membenarkan anda membuat ujian dengan menulis skrip (dalam kes Posmen, ini adalah JavaScript). Pendekatan ini mempunyai banyak kelebihan - fleksibiliti hampir tidak terhad, ketersediaan penyelesaian siap pakai, dsb.
Walau bagaimanapun, realitinya selalunya (kami tidak begitu, kehidupan begitu) bahawa penguji tidak mempunyai kemahiran pengaturcaraan, tetapi dia ingin membawa manfaat kepada pasukan sekarang. Untuk kes sedemikian, mengikut konsep tanpa kod, TestMace membolehkan anda membuat ujian mudah melalui GUI tanpa perlu menulis skrip. Di sini, sebagai contoh, ialah proses mencipta ujian yang membandingkan nilai untuk kesaksamaan kelihatan seperti:
Walau bagaimanapun, mencipta ujian dalam editor grafik tidak menghapuskan kemungkinan itu . Semua perpustakaan yang sama ada di sini seperti dalam nod skrip, dan untuk ujian menulis.
Keupayaan untuk menjalankan skrip sedia ada melalui pautan (Nod pautan)
Situasi sering timbul apabila pertanyaan tertentu atau bahkan keseluruhan skrip perlu dilaksanakan beberapa kali di bahagian projek yang berlainan. Contoh permintaan sedemikian boleh menjadi kebenaran berbilang peringkat tersuai, membawa persekitaran ke keadaan yang dikehendaki, dsb. Secara umum, bercakap dari segi bahasa pengaturcaraan, kami ingin mempunyai fungsi yang boleh digunakan semula di bahagian aplikasi yang berlainan. Dalam TestMace fungsi ini dilakukan oleh nod Ia sangat mudah untuk digunakan:
1) buat pertanyaan atau skrip
2) buat nod jenis Pautan
3) dalam parameter, nyatakan pautan ke skrip yang dibuat pada langkah pertama
Dalam versi yang lebih maju, anda boleh menentukan pembolehubah dinamik daripada skrip yang dihantar ke tahap yang lebih tinggi berbanding pautan. Bunyi mengelirukan? Katakan kami mencipta Folder dengan nama cipta-siaran, di mana pembolehubah dinamik diperuntukkan kepada nod ini postId. Sekarang dalam nod Pautan create-post-link anda boleh menyatakan dengan jelas bahawa pembolehubah postId ditugaskan kepada nenek moyang create-post-link. Mekanisme ini (sekali lagi, dalam bahasa pengaturcaraan) boleh digunakan untuk mengembalikan hasil daripada "fungsi". Secara umum, ia bagus, DRY sedang berjalan lancar dan sekali lagi tiada satu baris kod pun rosak.
Bagi Posman pula, terdapat permintaan ciri untuk permintaan penggunaan semula , dan nampaknya ada juga bahawa mereka sedang mengusahakan masalah ini. Dalam bentuk semasa, Posman, sudah tentu, mempunyai keupayaan untuk mengubah urutan pelaksanaan, yang secara teori mungkin memungkinkan untuk melaksanakan tingkah laku yang sama, tetapi ini lebih kepada penggodaman kotor daripada pendekatan yang benar-benar berfungsi.
Perbezaan lain
- Kawalan yang lebih besar ke atas skop pembolehubah. Skop terkecil di mana pembolehubah boleh ditakrifkan dalam Posman ialah pengumpulan. TestMace membolehkan anda menentukan pembolehubah untuk sebarang pertanyaan atau folder. Dalam koleksi Postman Share membolehkan anda mengeksport koleksi sahaja, manakala dalam TestMace perkongsian berfungsi untuk mana-mana nod
- TestMace menyokong , yang boleh digantikan kepada pertanyaan anak secara lalai. Posmen ada sesuatu tentang ini: , dan ia juga ditutup, tetapi ia ditawarkan sebagai penyelesaian... . Dalam TestMace, ini semua dikonfigurasikan melalui GUI dan terdapat pilihan untuk melumpuhkan pengepala yang diwarisi secara pilihan dalam keturunan tertentu
- Buat asal/Buat Semula. Berfungsi bukan sahaja semasa mengedit nod, tetapi juga apabila mengalih, memadam, menamakan semula dan operasi lain yang mengubah struktur projek
- Fail yang dilampirkan pada permintaan menjadi sebahagian daripada projek dan disimpan bersamanya, sambil disegerakkan dengan sempurna, tidak seperti Posmen. (Ya, anda tidak perlu lagi memilih fail secara manual setiap kali anda memulakan dan memindahkannya kepada rakan sekerja dalam arkib)
Ciri-ciri yang sedia ada
Kami tidak dapat menahan godaan untuk membuka tabir kerahsiaan pada keluaran seterusnya, terutamanya apabila fungsinya sangat lazat dan sedang menjalani penggilap pra-keluaran. Jadi, jom jumpa.
Fungsi
Seperti yang anda ketahui, Posmen menggunakan apa yang dipanggil pembolehubah dinamik untuk menjana nilai. dan sebahagian besar fungsi digunakan untuk menjana nilai palsu. Sebagai contoh, untuk menjana e-mel rawak anda perlu menulis:
{{$randomEmail}}Walau bagaimanapun, oleh kerana ini adalah pembolehubah (walaupun dinamik), ia tidak boleh digunakan sebagai fungsi: ia tidak boleh diparameterkan, oleh itu ia tidak mungkin untuk mengambil cincang daripada rentetan.
Kami merancang untuk menambah fungsi "jujur" pada TestMace. Betul-betul di dalam ${} adalah mungkin bukan sahaja untuk mengakses pembolehubah, tetapi juga untuk memanggil fungsi. Itu. jika anda perlu menjana e-mel palsu yang terkenal, kami hanya akan menulis
${faker.internet.email()}Sebagai tambahan kepada fakta bahawa ia adalah fungsi, anda akan melihat bahawa adalah mungkin untuk memanggil kaedah pada objek. Dan bukannya senarai besar pembolehubah dinamik yang rata, kami mempunyai satu set objek yang dikumpulkan secara logik.
Bagaimana jika kita ingin mengira cincang rentetan? Dengan mudah!
${crypto.MD5($dynamicVar.data)}Anda akan perasan bahawa anda juga boleh melepasi pembolehubah sebagai parameter! Pada ketika ini, pembaca yang ingin tahu mungkin mengesyaki ada sesuatu yang tidak kena...
Menggunakan JavaScript dalam Ungkapan
... Dan untuk alasan yang baik! Apabila keperluan untuk fungsi sedang dibentuk, kami tiba-tiba membuat kesimpulan bahawa javascript yang sah harus ditulis dalam ungkapan. Jadi sekarang anda bebas untuk menulis ungkapan seperti:
${1 + '' + crypto.MD5('asdf')}Dan semua ini tanpa skrip, betul-betul dalam medan input!
Bagi Posman, di sini anda hanya boleh menggunakan pembolehubah, dan apabila anda cuba menulis ungkapan yang sedikit, pengesah mengutuk dan enggan mengiranya.
Autolengkap lanjutan
Pada masa ini TestMace mempunyai autolengkap standard yang kelihatan seperti ini:
Di sini, sebagai tambahan kepada baris autolengkap, ia ditunjukkan kepunyaan baris ini. Mekanisme ini hanya berfungsi dalam ungkapan yang dikelilingi oleh kurungan ${}.
Seperti yang anda lihat, penanda visual telah ditambahkan yang menunjukkan jenis pembolehubah (contohnya, rentetan, nombor, tatasusunan, dll.). Anda juga boleh menukar mod autolengkap (contohnya, anda boleh memilih autolengkap dengan pembolehubah atau pengepala). Tetapi ini bukan perkara yang paling penting!
Pertama, autolengkap berfungsi walaupun dalam ungkapan (jika boleh). Inilah rupanya:
Dan kedua, autolengkap kini tersedia dalam skrip. Lihat bagaimana ia berfungsi!
Tidak ada gunanya membandingkan fungsi ini dengan Postman - autocompletion hanya terhad kepada senarai statik pembolehubah, pengepala dan nilainya (betulkan saya jika saya terlupa sesuatu). Skrip tidak dilengkapkan secara automatik :)
Kesimpulan
Oktober menandakan setahun sejak permulaan pembangunan produk kami. Pada masa ini, kami berjaya melakukan banyak perkara dan, dalam beberapa aspek, mengejar pesaing kami. Walau bagaimanapun, matlamat kami adalah untuk menjadikan alat yang benar-benar mudah untuk bekerja dengan API. Kami masih mempunyai banyak kerja yang perlu dilakukan, berikut adalah rancangan kasar untuk pembangunan projek kami untuk tahun yang akan datang: .
Maklum balas anda akan membolehkan kami menavigasi lebih banyak ciri, dan sokongan anda memberi kami kekuatan dan keyakinan bahawa kami melakukan perkara yang betul. Kebetulan hari ini adalah hari penting untuk projek kami - hari TestMace diterbitkan pada . Tolong sokong projek kami, ia sangat penting bagi kami. Lebih-lebih lagi, terdapat tawaran yang menarik di halaman PH kami hari ini, dan ia adalah terhad
Sumber: www.habr.com