单元测试中使用被测类的多个方法是否属于不良实践？

你遇到的这个场景很典型：实现栈结构时，push的测试要靠peek断言，peek的测试又得先用push造数据，一旦测试失败就没法直接定位是哪个方法出问题。但这种在单个单元测试里用被测类多个方法的做法，不一定是不良实践，核心在于怎么平衡测试的独立性和实际场景的合理性。

为什么会出现这种依赖？ #

像栈这种状态型数据结构，很多方法的行为本身就依赖其他方法修改的状态。peek的作用是获取栈顶元素，你总不能凭空测试它——必须先通过push把元素放进去；而push的效果，除了看内部状态（但暴露内部状态又违反封装原则），最直接的验证方式就是用peek或pop来确认元素是否正确入栈。

怎么解决“定位难”的问题？ #

虽然依赖无法完全避免，但可以通过优化测试用例来降低排查成本：

• 补充基础边界测试：先写不依赖其他方法的测试，比如测试空栈调用peek时的行为（比如是否抛出预期的异常）。这个测试只验证peek的基础逻辑，如果它失败，直接就能锁定peek有问题。
• 拆分测试粒度：把复杂场景拆成更基础的用例。比如先写“push单个元素后，peek返回该元素”的测试，这个用例同时验证push和peek，但逻辑最简单。如果这个用例失败，你可以优先排查这两个方法的基础逻辑；如果它通过，再去看“push多个元素”的复杂用例，此时大概率是push处理多个元素的逻辑有问题，而非peek。
• 交叉验证行为：比如补充push+pop的测试，用pop返回的结果来验证push的正确性，这样不用完全依赖peek。如果push+pop的测试通过，但push+peek的测试失败，那问题肯定出在peek上。

核心原则：测试行为而非孤立方法 #

单元测试的核心是验证软件的行为是否符合预期，而不是为了孤立每个方法而孤立。栈的核心特性是“后进先出”，push和peek本来就是协作完成这个特性的一部分。测试它们的协作行为，反而更贴近实际使用场景，能更有效地发现问题。

举个优化后的测试例子：

@Test
fun `peek empty stack throws exception`() {
    assertThrows<NoSuchElementException> { stack.peek() }
}

@Test
fun `push single element then peek returns it`() {
    stack.push("A")
    assertEquals("A", stack.peek())
}

@Test
fun `push multiple elements then peek returns last one`() {
    stack.push("A")
    stack.push("B")
    assertEquals("B", stack.peek())
}

@Test
fun `push element then pop returns it`() {
    stack.push("A")
    assertEquals("A", stack.pop())
}

这样一来，哪个测试失败，你就能快速缩小问题范围：比如peek empty stack失败→peek的边界逻辑有问题；push single element then peek失败→要么push没正确入栈，要么peek没正确取栈顶；push element then pop通过但前者失败→peek逻辑有问题。

内容的提问来源于stack exchange，提问作者Vivek Singh