Mit zunehmender Verbreitung von Miniprogrammen hat sich auch unsere Frontend-Entwicklungsarbeit von der reinen Webentwicklung auf die Cross-End-Entwicklung von Web- und Miniprogrammen ausgeweitet. Um die Forschungs- und Entwicklungseffizienz zu verbessern, müssen immer mehr Webmodule migriert, aktualisiert und mit Miniprogrammen kompatibel werden, um eine terminalübergreifende Wiederverwendung zu erreichen. Diese Module werden im Anschluss an das Geschäft auch Iterationen und Versionsaktualisierungen unterzogen. Zu diesem Zeitpunkt müssen wir gute Tests durchführen, um die Zuverlässigkeit jedes Endmoduls sicherzustellen.
Da wir viele bestehende Webmodule auf Miniprogramme migriert haben, sind die Tests auf der Webseite relativ abgeschlossen. Daher müssen wir Folgendes berücksichtigen:
Wie man bestehende Web-Anwendungsfälle schnell in kleine Programme migriert
Wie man beide End-Anwendungsfälle schnell für neue Module schreibt.
(Wir verwenden hauptsächlich die Kombination von Puppeteer und Jest auf der Webseite.)
Sie können direkt zur endgültigen Lösung wechseln
Unsere aktuellen Module sind hauptsächlich die folgenden drei Typen:
Typ-1-Module sind nicht durch die Umgebung eingeschränkt und können Komponententests mit dem Web teilen, ohne dass zusätzliche erforderlich sind Testfallentwicklung.
Typ-3-Module sind aufgrund der großen Unterschiede zwischen dem Miniprogramm und dem Web schwierig wiederzuverwenden (derzeit basiert unsere Web-UI-Ebene hauptsächlich auf React, und das Miniprogramm wird nativ entwickelt, während bei einigen mit kbone für die isomorphe Entwicklung zusammengearbeitet wird). Seiten).
Wir migrieren hier hauptsächlich Testfälle für Typ-2-Module.
Der Miniprogrammbeamte stellt derzeit zwei Tools zur Unterstützung des Miniprogrammtests zur Verfügung:
Durch die Kombination offizieller Tools mit Test-Frameworks wie Jest und Mocha können wir Tests in einer Miniprogrammumgebung implementieren.
Wir haben uns für Mini Program Automation entschieden. Ähnlich wie beim Ausführen von Website-Tests in Puppeteer können wir das Miniprogramm automatisieren und die Entwicklertools steuern, um Tests in der Miniprogrammumgebung umzusetzen. Die Ähnlichkeiten zwischen den beiden bieten uns die Möglichkeit einer Cross-End-Migration und sogar der Wiederverwendung von Testfällen.
Nehmen Sie die Migration eines Testfalls eines Berichtsmoduls als Beispiel. Im Folgenden sehen Sie einen Testfall unseres vorhandenen Web-Berichtsmoduls.
Der von diesem Fall abgedeckte Pfad ist: 调用imlog.default.error()方法 -> 浏览器将发起请求 -> 对请求参数进行校验
.
test('.error()调用正常', async done => { const opts = { project: 'imlogtest', }; // 检查上报请求的参数 const expector = req => { try { const url = req.url(); const method = req.method(); const headers = req.headers(); const body = req.postData(); const data = JSON.parse(body); expect(url).toBe(DEFAULT_URL); // 请求的url符合预期 expect(method).toBe('POST'); // 请求的method符合预期 expect(headers['content-type']).toBe('text/plain'); // 请求的contentType符合预期 expect(data.url).toBe(TEST_PAGE_URL); // 请求体的url字段符合预期 done(); } catch(error) { done(error); } }; // 监听上报请求并校验参数 page.once('request', expector); // 在浏览器中执行上报 page.evaluate( (o) => { const reportor = window.imlog.default; reportor.config(o); reportor.error('test'); // 进行上报 }, opts ); });复制代码
Das Obige verwendet hauptsächlich die Page API von Puppeteer.
Die Automatisierung von Miniprogrammen stellt uns einige APIs zur Verfügung, die dem Puppenspieler ähneln:
Wenn das Miniprogramm wie Puppeteer funktioniert, verwendet es Abhörereignisse, um die Aufrufparameter der wx-API abzufangen, und das Schreiben von Testfällen wird viel einfacher. Der Anwendungsfall für ein Miniprogramm, den wir uns vorstellen, wird die folgende Form haben:
test('.error()调用正常', async done => { const opts = { project: 'imlogtest', }; // 检查上报请求的参数 const expector = req => { try { // diff:按照特定格式解析出小程序请求参数 const {url, method, headers, body, data} = parseWxReqParams(req); expect(url).toBe(DEFAULT_URL); // 请求的url符合预期 expect(method).toBe('POST'); // 请求的method符合预期 expect(headers['content-type']).toBe('text/plain'); // 请求的contentType符合预期 expect(data.url).toBe(TEST_PAGE_URL); // 请求体的url字段符合预期 done(); } catch(error) { done(error); } }; // 监听上报请求并校验参数 // todo: miniProgram对象支持once/on等事件方法 miniProgram.once('request', expector); // 在小程序中执行上报 miniProgram.evaluate( (o) => { // diff: 请求方法挂在小程序app对象上 const reportor = getApp().imlog.default; reportor.config(o); reportor.error('test'); // 进行上报 }, opts ); });复制代码
Solange wir eine Möglichkeit finden, die Parameter zu überwachen, die beim Aufruf der API über miniProgram.on('api', fn) in Form von Ereignissen übergeben werden .
In dieser Form besteht der Unterschied zwischen Web- und Miniprogramm-Anwendungsfällen nur darin:
Beobachten Sie zunächst das miniProgram-Objekt über die von MiniProgram.d.ts bereitgestellten Miniprogram-Automator: Sie können feststellen, dass die MiniProgram-Klasse selbst von EventEmitter geerbt wurde.
import { EventEmitter } from 'events';export default class MiniProgram extends EventEmitter { // ...}复制代码
Der nächste Schritt besteht darin, eine Möglichkeit zu finden, die Emit-Methode des miniProgram-Objekts auszulösen, wenn die API aufgerufen wird.
Es gibt zwei Automatisierungs-APIs, die uns dabei helfen können, dies zu erreichen.
miniProgram.mockWxMethod ermöglicht es uns, das Ergebnis des Aufrufs der angegebenen Methode für das WX-Objekt zu überschreiben.
miniProgram.exposeFunction stellt Methoden global in AppService bereit, damit das Miniprogramm Methoden in Testskripten aufrufen kann.
In diesem Moment kam mir eine mutige Idee
Das obige ist der detaillierte Inhalt vonWX-API-Abfangen für automatisierte Tests kleiner Programme. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!