测试 — $mol

测试

$mol 的视图是它自身状态的函数，这也改变了测试的样子。一个用户场景就写成对视图自己方法的调用：设置草稿、执行动作、读取用户会看到的东西。1app.draft( 'Milk' )2app.add()3$mol_assert_equal( app.item_title( 0 ), 'Milk' )没有选择器，没有浏览器，没有 Playwright 或 Cypress，也不用等待任何东西。同一个文件还给你：速度。测试在 Node 里以毫秒计地跑完；一千个大约一分钟。node my/hello/-/node.test.js 跑的是某个模块的那些测试。零配置。组件旁边的 hello.test.ts 会被构建器捡起来，编译进 -/node.test.js。用 mam_build 做持续集成时会运行它，测试失败就让构建失败。通过上下文替换服务。每个测试都拿到自己的 $，组件经由 this.$.X 取到的一切，都可以通过往那个 $ 上赋一个测试替身来换掉。这正是要写 this.$.$mol_fetch 而不是 $mol_fetch 的理由：前者可替换，后者不可。被模拟的时间。经由上下文创建的定时器不会自己走动；$mol_after_mock_warp() 会把排队的东西跑掉。需要时有真实的 DOM。 Node 的打包产物自带 jsdom，所以 dom_node() 和 querySelectorAll 在同一个测试文件里就能用。

用视图方法走一遍场景

拿

食谱里的待办列表来说：一个 draft? 字符串、一个 items 列表、一个 add 动作和一个 delete 动作。它的测试住在 my/todo/todo.test.ts：1namespace $ {2 $mol_test({3 4 'add an item and delete it'( $ ) {5 const app = $my_todo.make({ $ })6 7 app.draft( 'Milk' )8 app.add()9 $mol_assert_equal( app.items().length, 1 )10 $mol_assert_equal( app.item_title( 0 ), 'Milk' )11 $mol_assert_equal( app.draft(), '' )12 13 app.delete( 0 )14 $mol_assert_like( app.item_rows(), [] )15 },16 17 'blank draft adds nothing'( $ ) {18 const app = $my_todo.make({ $ })19 20 app.draft( ' ' )21 app.add()22 $mol_assert_like( app.items(), [] )23 },24 25 })26}有几点值得注意：在 GitHub 上编辑此页这有帮助吗？是否上一页渲染下一页部署本页内容用视图方法走一遍场景模拟一个服务时间穿过 DOM Node 测试覆盖不到什么实用提示下一步