À mesure que les mini-programmes sont de plus en plus utilisés, notre travail de développement front-end a également évolué du pur développement Web. étendre au développement cross-end de web + petits programmes. Afin d'améliorer l'efficacité de la recherche et du développement, de plus en plus de modules Web doivent être migrés, mis à jour et compatibles avec des mini-programmes pour parvenir à une réutilisation entre terminaux . Ces modules subiront également des itérations et des mises à jour de version en fonction de l'activité. À ce stade, nous avons besoin de bons tests pour garantir la fiabilité de chaque module final.
Depuis que nous avons migré de nombreux modules web existants vers des mini programmes, les tests côté web sont relativement complets. Par conséquent, ce que nous devons considérer est :
Comment migrer rapidement les cas d'utilisation Web existants vers de petits programmes
Pour les nouveaux modules, comment rédiger rapidement des cas d'utilisation aux deux extrémités.
(Nous utilisons principalement la combinaison de Puppeteer et Jest côté web.)
Vous pouvez passer directement à la solution finale
Nos modules actuels sont principalement des trois types suivants :
Les modules de type 1 ne sont pas limités par l'environnement et peuvent partager des tests unitaires avec le Web sans avoir besoin de développement de cas de test supplémentaire.
Les modules de type 3 sont difficiles à réutiliser en raison des grandes différences entre le mini-programme et le Web (actuellement, notre couche d'interface utilisateur Web est principalement basée sur React, et le mini-programme utilise le développement natif et coopère également avec kbone développer quelques pages Développement isomorphe).
Nous migrons ici principalement des cas de tests pour les modules de Type 2.
Le responsable du mini-programme fournit actuellement deux outils pour prendre en charge les tests de mini-programmes :
En combinant des outils officiels avec des frameworks de test tels que Jest et Mocha, nous pouvons implémenter des tests dans un petit environnement de programme.
Nous avons choisi Mini Program Automation. Semblable à l'exécution de tests côté Web dans Puppeteer, nous pouvons automatiser le mini-programme et contrôler les outils de développement pour implémenter les tests dans l'environnement du mini-programme. Les similitudes entre les deux nous offrent la possibilité d'une migration croisée et même de réutilisation des cas de test.
Prenons comme exemple la migration d'un cas de test d'un module de reporting Ce qui suit est un cas de test d'un module de reporting Web que nous avons déjà.
Le chemin couvert par ce cas est : 调用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
);
});复制代码Ce qui précède utilise principalement l'API Page de Puppeteer.
L'automatisation de mini-programmes nous fournit quelques API similaires à Puppeteer :
Si le mini programme peut ressembler à Puppeteer, il peut intercepter les paramètres d'appel de l'API wx sous forme d'événements d'écoute, l'écriture des cas de tests sera beaucoup plus simple. Le cas d'utilisation du mini programme que nous imaginons se présentera sous la forme suivante :
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
);
});复制代码Tant que nous trouvons un moyen de surveiller l'appel via miniProgram.on('api', fn) sous la forme de events Paramètres transmis lors de l’API.
Sous cette forme, la différence entre les cas d'utilisation du web et du mini programme est seulement :
Observez d'abord l'objet miniProgram. Grâce au MiniProgram.d.ts exposé par miniprogram-automator, vous pouvez constater que la classe MiniProgram elle-même hérite d'EventEmitter.
import { EventEmitter } from 'events';export default class MiniProgram extends EventEmitter { // ...}复制代码Ensuite, vous devez trouver un moyen de déclencher la méthode d'émission de l'objet miniProgram lorsque l'API est appelée.
Il existe deux API d'automatisation qui peuvent nous aider à y parvenir.
miniProgram.mockWxMethod nous permet de remplacer le résultat de l'appel de la méthode spécifiée sur l'objet wx.
miniProgram.exposeFunction expose les méthodes globalement dans AppService pour que les mini-programmes appellent des méthodes dans des scripts de test.
À ce moment-là, une idée audacieuse m'est venue à l'esprit
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
