describe 和 it 用于分层组织测试：describe 定义功能上下文并支持嵌套以表达模块→类→方法→场景层级，it 声明具体行为断言，每个 it 应聚焦单一场景并用动词开头的完整句式描述行为。
用 describe 和 it 组织测试，本质是给测试逻辑“分层归类”——describe 定义一组相关功能的上下文，it 描述该上下文下的具体行为表现。这不是语法强制要求，而是测试可读性与可维护性的关键实践。
describe 用于划定测试范围和主题
describe 接收一个字符串描述和一个回调函数，把一组语义相关的测试包裹起来。它支持嵌套，适合表达“模块 → 类 → 方法 → 场景”的层级关系。
- 顶层
describe通常对应被测对象名称，比如"Player"、"add function" - 嵌套的
describe可表达状态或条件，例如"when song has been paused"、"with invalid input" - 每个
describe块可配beforeEach或afterEach，用于统一准备/清理环境，避免重复代码
it（或 test）用于声明具体行为断言
it 是最小可执行测试单元，必须放在某个 describe 内部。它的字符串描述应是一个完整的、以动词开头的行为句式，清晰表达“在什么条件下，发生什么，得到什么结果”。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 推荐写法：
it("should play a song when play() is called"，而不是"test play method" - 每个
it应聚焦单一场景：正常流程、边界值、错误输入、异步响应等都应拆成独立it - 内部使用
expect(...).toBe(...)等断言验证结果，不建议在一个it里做多个不相关的断言
典型结构示例（Jest/Mocha 风格）
以下结构清晰体现分层逻辑：
describe("Calculator", () => {
describe("add method", () => {
it("returns the sum of two positive numbers", () => {
expect(add(2, 3)).toBe(5);
});
it("handles negative numbers correctly", () => {
expect(add(-1, 4)).toBe(3);
});
});
describe("divide method", () => {
it("returns correct result for valid inputs", () => {
expect(divide(10, 2)).toBe(5);
});
it("throws error when dividing by zero", () => {
expect(() => divide(5, 0)).toThrow("Division by zero");
});
});
});
注意事项
过度嵌套会增加理解成本；一般不超过三层 describe。若发现某层 describe 下只有 1–2 个 it，或描述难以统一，说明分类可能不合理，应回顾被测代码职责是否内聚。
