假设您实现了一个Stack数据结构，并且正在编写一个push和peek操作的测试。
@Test
fun `push an element in the stack`() {
stack.push("A")
stack.push("B")
assertEquals("B", stack.peek())
}
@Test
fun `peek from an non empty stack`() {
stack.push("A")
stack.push("B")
stack.push("C")
assertEquals("C", stack.peek())
}
对于push操作的测试也需要从堆栈中窥视以做出断言，类似地，对于peek操作的测试需要将栈压入以从堆栈中窥视。
假设对于push测试用例，如果测试失败，我们如何知道是push方法失败还是peek方法失败。
那么，在测试类的单个单元测试中使用多个方法是一种不好的做法吗?
在测试类的单个单元测试中使用多个方法是不好的做法吗
这真的不是一个坏的做法。人们常常认为他们应该为类的每个方法编写单元测试，但事实并非如此。
单元测试是用来根据预期的行为来测试类的行为。这很可能需要调用几个方法来进行正确的设置和断言。
即使在最简单的情况下，使用某种方法来设置某种状态，然后使用另一种方法来查询状态也是很常见的。你的例子是一个很好的例子，你需要推送一些数据，然后查询它。这没什么不对的。
我认为你们当前测试设计中的概念问题在测试的命名上是显而易见的。您的两个测试实际上都在测试相同的行为:peek on non-empty stack should return the last pushed element。你不能(也不应该)对push和peek分别进行一次测试。相反，您只能测试它们如何相互作用。
相反，单个方法可以用于许多单元测试，以测试不同的用例(特别是边缘用例)。所以在多个单元测试中使用push和peek也是可以的。
如果测试失败如何知道是push方法失败还是peek方法失败
测试失败不应该告诉你哪段代码被破坏了，它应该告诉你什么行为不符合规范(不再)。调查bug在哪里是开发人员的工作(如果不明显的话)。通常情况下，如果你有很好的重点测试(这并不意味着单方法测试)，真的不难发现哪里出了问题。如果遇到困难，可以使用调试器来帮助检查不同时间点的中间状态。