tdd-workflow — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited tdd-workflow (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
bensz-collect-bugs 规范记录到 ~/.bensz-skills/bugs/，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务。gh 上传新增 bug 到 huangwb8/bensz-bugs；不要 pull / clone 整个仓库。NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST违反规则的信件就是违反规则的精神。
无例外：
| 借口 | 现实 |
|---|---|
| "太简单不需要测试" | 简单代码也会坏。测试只需 30 秒 |
| "我之后再测试" | 测试立即通过证明不了什么 |
| "测试后达到相同目的" | 测试后="代码做什么?"测试前="代码应该做什么?" |
| "已经手动测试了" | 临时≠系统化。无记录，无法重新运行 |
| "删除 X 小时工作是浪费" | 沉没成本谬误。保留未验证代码是技术债 |
| "保留参考，先写测试" | 你会调整它。那是测试后。删除=删除 |
所有这些意味着：删除代码。用 TDD 重新开始。
测试驱动开发（Test-Driven Development, TDD） 是一种先编写测试，再编写实现代码的开发方法。通过严格的 Red-Green-Refactor 循环，确保代码质量和可维护性。
┌─────────────────────────────────────────────────────────┐
│ 1. RED : 编写失败的测试 │
│ 2. GREEN : 编写最简单的代码使测试通过 │
│ 3. REFACTOR: 在测试保护下重构代码 │
│ 4. 重复循环 │
└─────────────────────────────────────────────────────────┘在以下场景时激活：
在开始编码前，明确：
测试先行原则：
测试命名规范（AAA 模式）：
# Should_预期行为_When_测试条件
def should_return_user_when_id_exists():
# Arrange（准备）
user_id = 123
expected_user = User(id=123, name="Alice")
# Act（执行）
result = user_service.get_by_id(user_id)
# Assert（断言）
assert result.id == expected_user.id
assert result.name == expected_user.name最简单的可工作代码：
# 最初版本 - 硬编码也可以
def get_by_id(user_id):
if user_id == 123:
return User(id=123, name="Alice")
return None# 运行测试
pytest tests/test_user_service.py -v
# 期望输出
✅ should_return_user_when_id_exists PASSED在测试保护下优化：
# 重构后版本
def get_by_id(user_id):
return _user_repository.find_by_id(user_id)每个功能点重复上述步骤，直到功能完整。
# 好的示例 - 使用 fixtures
@pytest.fixture
def clean_database():
db.reset()
yield
db.cleanup()
def test_create_user(clean_database):
user = user_service.create("Alice")
assert user.name == "Alice"def test_get_by_id():
# 正常情况
assert get_user(1) is not None
# 边界条件
assert get_user(0) is None
assert get_user(-1) is None
assert get_user(999999) is Nonedef test_create_user_with_duplicate_email():
with pytest.raises(DuplicateEmailError):
user_service.create("[email protected]")
user_service.create("[email protected]")# 测试
def should_calculate_total_price():
cart = ShoppingCart()
cart.add_item(Item(name="Book", price=10))
cart.add_item(Item(name="Pen", price=5))
assert cart.total_price() == 15
# 实现
class ShoppingCart:
def __init__(self):
self.items = []
def add_item(self, item):
self.items.append(item)
def total_price(self):
return sum(item.price for item in self.items)// 测试
test('should calculate total price', () => {
const cart = new ShoppingCart();
cart.addItem({ name: 'Book', price: 10 });
cart.addItem({ name: 'Pen', price: 5 });
expect(cart.totalPrice()).toBe(15);
});
// 实现
class ShoppingCart {
constructor() {
this.items = [];
}
addItem(item) {
this.items.push(item);
}
totalPrice() {
return this.items.reduce((sum, item) => sum + item.price, 0);
}
}// 测试
test('should calculate total price', () => {
const cart = new ShoppingCart();
cart.addItem({ name: 'Book', price: 10 });
cart.addItem({ name: 'Pen', price: 5 });
expect(cart.totalPrice()).toBe(15);
});
// 实现
interface Item {
name: string;
price: number;
}
class ShoppingCart {
private items: Item[] = [];
addItem(item: Item): void {
this.items.push(item);
}
totalPrice(): number {
return this.items.reduce((sum, item) => sum + item.price, 0);
}
}A: 不一定。80-90% 是合理目标。以下情况可以例外：
A: 不要直接测试私有方法。应该通过公共接口测试其行为。如果私有方法太复杂，考虑提取到独立的类。
A: 短期可能稍慢，但长期来看：
A:
完成 TDD 开发后，检查：
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.