3 个代码块跑通 Obsidian-skills 测试从环境搭建到 CI 的任务流【免费下载链接】obsidian-skillsAgent skills for Obsidian. Teach your agent to use Obsidian CLI and open formats including Markdown, Bases, JSON Canvas.项目地址: https://gitcode.com/GitHub_Trending/ob/obsidian-skills你让 AI 代理批量生成 Obsidian 笔记和画布时Obsidian-skills 测试就是你的安全网。本文按任务流走一遍搭环境、跑通第一个语法校验用例、覆盖五个技能、接入 CI。 为什么必须测从一个打开就报错的画布说起这节回答一个问题测试到底防住什么事故。想象这样一个下午你让代理整理一份思维导图它交给你一个.canvas文件Obsidian 打开却直接报解析错误。翻出来看问题多半藏在细节里——某个节点 ID 和已有节点撞了号一条边的fromNode指向了一个根本不存在的节点或者文本节点里被写进了字面量\\n于是画面上老老实实显示反斜杠加 n 这两个字符而不是换行。问题不在于代理笨而在于它没有眼睛。它写完.canvas就认为任务完成了而你是第一个打开验证的人。测试要做的就是替你提前完成这一步把打开文件、肉眼检查变成一段可重复执行的校验脚本让代理产出的每个文件先过机检再进你的保险库。这也是 Obsidian-skills 测试的核心动机——它测的不是代码而是代理输出的文件本身是否合法。️ 先拿地图再上路四层测试体系各管什么这节解决测试体系全景的问题让你心里先有一张分层表后面的用例往格子里填就行。层测什么一个具体例子单元测试单个字段、单段语法节点 ID 是不是 16 位十六进制、是否全局唯一集成测试技能之间的协作defuddle抽出的正文交给obsidian-markdown写进笔记后语法依然合法端到端测试完整用户链路从给一个网页链接到知识库里出现一条整理好的笔记性能测试规模与耗时几百个节点的画布、大量笔记的检索还能不能在可接受时间内完成四层不用平均用力。日常开发主要靠单元测试和集成测试兜底端到端和性能测试在发版前跑一轮即可——原文里常说的分层架构落到操作上就是这个节奏。️ 测试环境最快搭建方式从装依赖到接入 CI翻车最多的一步在这里但也是见效最快的一步。搭好测试环境准备工作只有三件事装外部依赖、准备测试数据。依赖就两个# 装齐外部依赖后面 CLI 和网页提取用例都依赖它们 npm install -g obsidian-cli npm install -g defuddle测试数据不用造得很全一份含各种 Markdown 语法元素的样例笔记、一个多字段的小型.base数据库、一张带几种节点和边的.canvas、以及几页结构各异的网页够五个技能各有一组输入就行。如何跑通第一个语法校验用例从json-canvas下手因为它的规则最硬、最容易写成断言。拿一个代理生成的画布跑这段最小校验# canvas 最小校验ID 唯一 边引用完整 import json data json.load(open(sample.canvas)) ids [n[id] for n in data[nodes]] assert len(set(ids)) len(ids), 存在重复的节点 ID id_set set(ids) for e in data[edges]: assert e[fromNode] in id_set and e[toNode] in id_set, 边引用了不存在的节点跑通这一条你就有了模板读文件、解析、断言。后面所有技能的用例都是在这个骨架上换断言条件。把五个技能逐一纳入测试每个技能记住一个测什么清单和一条最小用例即可不必每个都写成大套件。obsidian-markdownskills/obsidian-markdown/SKILL.md。测什么维基链接[[Note]]及其#Heading变体、标注框 [!note]、高亮高亮、脚注[^1]这类专属语法是否完整生成。最小用例让代理写一段含标注框加内链的笔记断言[[和 [!都成对闭合。obsidian-basesskills/obsidian-bases/SKILL.md。测什么.base里view、filter、sort、formula字段及Text、Number、Date等类型声明。最小用例建一个只有三行数据的小型库断言过滤器命中了预期行、排序结果顺序正确。json-canvasskills/json-canvas/SKILL.md。测什么ID 为 16 位十六进制且唯一、type只取text/file/link/group、尺寸合理文本节点约 300–450px文件节点 300–500px、新节点与旧节点保持 50–100px 间距、fromSide/toSide只在 top/right/bottom/left 里取值。最小用例给一个已有画布追加节点后重跑上面的校验脚本。obsidian-cliskills/obsidian-cli/SKILL.md。测什么read、create、append的文件操作property:set/property:get的属性往返以及plugin:reload→dev:errors→dev:screenshot这条插件开发回路。最小用例create一条笔记后read回来断言内容逐字一致。defuddleskills/defuddle/SKILL.md。测什么--md输出是干净 Markdown、--json结构完整、-p title/-p description/-p domain三个元数据不为空。最小用例解析一个样例页面断言标题非空且正文里没有导航残留。接入持续集成把上面的脚本挂进 CIObsidian-skills 测试用例才算真正活着name: obsidian-skills 测试 on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - run: npm install -g obsidian-cli defuddle # 与本地环境保持一致 - run: python test_canvas.py # 其余技能脚本同理追加执行节奏可以很简单每次改动后跑语法类快测提交前跑完整套件发版前补端到端和性能。 用例设计方法论一段输入、一个预期、一次验证用例写多少才算够答案不在数量而在结构。每条用例都按输入 / 预期 / 验证三段写写不出三段的就是伪用例。段落写什么例子输入具体的、可复现的触发条件一段含引号、破折号等特殊字符的正文预期输出应当满足的可断言条件特殊字符被正确转义渲染不破坏验证怎么确认断言还是人工预览断言关键字段 Obsidian 预览模式目检在这个模板之上三类用例各有取舍标准边界值优先花在尺寸和数量上——最小/最大节点宽高、节点数压到几百个因为这类错误几乎总是恰好越界才触发。异常输入优先花在外部依赖路径上——空保险库、文件不存在、页面抓取失败代理对坏输入的反应直接决定你保险库的安全性。错误恢复只放在关键路径上——一次失败后重试能否得到一致结果值得测锦上添花的路径就不必了。 排障别靠猜一张故障速查表这节给你一张现象 → 可能原因 → 处理动作的对照表出问题时按行对号入座。现象可能原因处理动作.canvas打开即报错节点 ID 重复或边引用了不存在的节点重跑 ID 唯一性与引用完整性校验语法校验本地过、线上挂Obsidian 版本差异确认 CI 与本地使用的版本一致性能测试超时数据规模过大缩小测试数据或单独调高超时阈值集成测试失败两个技能间输入输出对不上分别打印中间产物核对接口一致性还有一条通用调试顺序先开详细日志再用测试替身把外部依赖隔离掉然后把大场景拆成小步逐个执行每一步都记录预期与实际的差异。顺序反过来——先猜再验证——是最费时间的走法。今天就做一件事挑你手头最常用的一个技能给它补 3 个语法用例——一个正常输入、一个边界值、一个坏 JSON。跑通它们你手里就有了第一版真正能挡事故的 Obsidian-skills 测试。【免费下载链接】obsidian-skillsAgent skills for Obsidian. Teach your agent to use Obsidian CLI and open formats including Markdown, Bases, JSON Canvas.项目地址: https://gitcode.com/GitHub_Trending/ob/obsidian-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 3 个代码块跑通 Obsidian-skills 测试：从环境搭建到 CI 的任务流
3 个代码块跑通 Obsidian-skills 测试从环境搭建到 CI 的任务流【免费下载链接】obsidian-skillsAgent skills for Obsidian. Teach your agent to use Obsidian CLI and open formats including Markdown, Bases, JSON Canvas.项目地址: https://gitcode.com/GitHub_Trending/ob/obsidian-skills你让 AI 代理批量生成 Obsidian 笔记和画布时Obsidian-skills 测试就是你的安全网。本文按任务流走一遍搭环境、跑通第一个语法校验用例、覆盖五个技能、接入 CI。 为什么必须测从一个打开就报错的画布说起这节回答一个问题测试到底防住什么事故。想象这样一个下午你让代理整理一份思维导图它交给你一个.canvas文件Obsidian 打开却直接报解析错误。翻出来看问题多半藏在细节里——某个节点 ID 和已有节点撞了号一条边的fromNode指向了一个根本不存在的节点或者文本节点里被写进了字面量\\n于是画面上老老实实显示反斜杠加 n 这两个字符而不是换行。问题不在于代理笨而在于它没有眼睛。它写完.canvas就认为任务完成了而你是第一个打开验证的人。测试要做的就是替你提前完成这一步把打开文件、肉眼检查变成一段可重复执行的校验脚本让代理产出的每个文件先过机检再进你的保险库。这也是 Obsidian-skills 测试的核心动机——它测的不是代码而是代理输出的文件本身是否合法。️ 先拿地图再上路四层测试体系各管什么这节解决测试体系全景的问题让你心里先有一张分层表后面的用例往格子里填就行。层测什么一个具体例子单元测试单个字段、单段语法节点 ID 是不是 16 位十六进制、是否全局唯一集成测试技能之间的协作defuddle抽出的正文交给obsidian-markdown写进笔记后语法依然合法端到端测试完整用户链路从给一个网页链接到知识库里出现一条整理好的笔记性能测试规模与耗时几百个节点的画布、大量笔记的检索还能不能在可接受时间内完成四层不用平均用力。日常开发主要靠单元测试和集成测试兜底端到端和性能测试在发版前跑一轮即可——原文里常说的分层架构落到操作上就是这个节奏。️ 测试环境最快搭建方式从装依赖到接入 CI翻车最多的一步在这里但也是见效最快的一步。搭好测试环境准备工作只有三件事装外部依赖、准备测试数据。依赖就两个# 装齐外部依赖后面 CLI 和网页提取用例都依赖它们 npm install -g obsidian-cli npm install -g defuddle测试数据不用造得很全一份含各种 Markdown 语法元素的样例笔记、一个多字段的小型.base数据库、一张带几种节点和边的.canvas、以及几页结构各异的网页够五个技能各有一组输入就行。如何跑通第一个语法校验用例从json-canvas下手因为它的规则最硬、最容易写成断言。拿一个代理生成的画布跑这段最小校验# canvas 最小校验ID 唯一 边引用完整 import json data json.load(open(sample.canvas)) ids [n[id] for n in data[nodes]] assert len(set(ids)) len(ids), 存在重复的节点 ID id_set set(ids) for e in data[edges]: assert e[fromNode] in id_set and e[toNode] in id_set, 边引用了不存在的节点跑通这一条你就有了模板读文件、解析、断言。后面所有技能的用例都是在这个骨架上换断言条件。把五个技能逐一纳入测试每个技能记住一个测什么清单和一条最小用例即可不必每个都写成大套件。obsidian-markdownskills/obsidian-markdown/SKILL.md。测什么维基链接[[Note]]及其#Heading变体、标注框 [!note]、高亮高亮、脚注[^1]这类专属语法是否完整生成。最小用例让代理写一段含标注框加内链的笔记断言[[和 [!都成对闭合。obsidian-basesskills/obsidian-bases/SKILL.md。测什么.base里view、filter、sort、formula字段及Text、Number、Date等类型声明。最小用例建一个只有三行数据的小型库断言过滤器命中了预期行、排序结果顺序正确。json-canvasskills/json-canvas/SKILL.md。测什么ID 为 16 位十六进制且唯一、type只取text/file/link/group、尺寸合理文本节点约 300–450px文件节点 300–500px、新节点与旧节点保持 50–100px 间距、fromSide/toSide只在 top/right/bottom/left 里取值。最小用例给一个已有画布追加节点后重跑上面的校验脚本。obsidian-cliskills/obsidian-cli/SKILL.md。测什么read、create、append的文件操作property:set/property:get的属性往返以及plugin:reload→dev:errors→dev:screenshot这条插件开发回路。最小用例create一条笔记后read回来断言内容逐字一致。defuddleskills/defuddle/SKILL.md。测什么--md输出是干净 Markdown、--json结构完整、-p title/-p description/-p domain三个元数据不为空。最小用例解析一个样例页面断言标题非空且正文里没有导航残留。接入持续集成把上面的脚本挂进 CIObsidian-skills 测试用例才算真正活着name: obsidian-skills 测试 on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - run: npm install -g obsidian-cli defuddle # 与本地环境保持一致 - run: python test_canvas.py # 其余技能脚本同理追加执行节奏可以很简单每次改动后跑语法类快测提交前跑完整套件发版前补端到端和性能。 用例设计方法论一段输入、一个预期、一次验证用例写多少才算够答案不在数量而在结构。每条用例都按输入 / 预期 / 验证三段写写不出三段的就是伪用例。段落写什么例子输入具体的、可复现的触发条件一段含引号、破折号等特殊字符的正文预期输出应当满足的可断言条件特殊字符被正确转义渲染不破坏验证怎么确认断言还是人工预览断言关键字段 Obsidian 预览模式目检在这个模板之上三类用例各有取舍标准边界值优先花在尺寸和数量上——最小/最大节点宽高、节点数压到几百个因为这类错误几乎总是恰好越界才触发。异常输入优先花在外部依赖路径上——空保险库、文件不存在、页面抓取失败代理对坏输入的反应直接决定你保险库的安全性。错误恢复只放在关键路径上——一次失败后重试能否得到一致结果值得测锦上添花的路径就不必了。 排障别靠猜一张故障速查表这节给你一张现象 → 可能原因 → 处理动作的对照表出问题时按行对号入座。现象可能原因处理动作.canvas打开即报错节点 ID 重复或边引用了不存在的节点重跑 ID 唯一性与引用完整性校验语法校验本地过、线上挂Obsidian 版本差异确认 CI 与本地使用的版本一致性能测试超时数据规模过大缩小测试数据或单独调高超时阈值集成测试失败两个技能间输入输出对不上分别打印中间产物核对接口一致性还有一条通用调试顺序先开详细日志再用测试替身把外部依赖隔离掉然后把大场景拆成小步逐个执行每一步都记录预期与实际的差异。顺序反过来——先猜再验证——是最费时间的走法。今天就做一件事挑你手头最常用的一个技能给它补 3 个语法用例——一个正常输入、一个边界值、一个坏 JSON。跑通它们你手里就有了第一版真正能挡事故的 Obsidian-skills 测试。【免费下载链接】obsidian-skillsAgent skills for Obsidian. Teach your agent to use Obsidian CLI and open formats including Markdown, Bases, JSON Canvas.项目地址: https://gitcode.com/GitHub_Trending/ob/obsidian-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考