写一个很长(超过200行)的测试方法真是太糟糕了吗?或者我应该把它分解成更小的方法吗?
答案 0 :(得分:11)
你不应该(总体上)创建任何200行长的方法。如果你可以分手,那就去做吧。
你在200行做什么?单元测试应该测试小的代码单元。这200条线主要是断言吗?如果是这样,那可能没问题。
关键问题是 - 有人能够快速了解该方法的作用,还是难以理解?
“程序应该主要编写为由人们阅读,并且只是偶然由机器运行。” (Abelson& Sussman,计算机程序的结构和解释)
答案 1 :(得分:4)
200行听起来太长了。单元测试方法就像任何其他方法一样。您应该尽可能使用"Extract Method"重构。这将提高代码的可读性。
修改 - 由于您的测试时间很长,它也可能会出现许多测试气味,例如Eager Test。
通常在我写的测试中,我喜欢快速查看Arrange/Act/Assert。如果你有超过200行,那么很可能很难分辨哪一位在哪里。
答案 2 :(得分:2)
您询问是否应该将其分解的事实表明您可以将其分解。我认为特别是单元测试应该尽可能小,并且每个测试只测试软件的一个方面。
答案 3 :(得分:1)
我会质疑大多数接近200行的任何方法。打破它应该增加内在的代码可读性,并且可能有助于更准确地识别失败区域或者像猫一样开始咕噜声:当然这取决于所讨论的方法,使用的语言和测试框架。
哦,很可能: - )
答案 4 :(得分:1)
长期方法是不受欢迎的。它们通常表明方法做得太多了。
同样适用于单元测试,如果不是这样的话。理想情况下,您应该能够通过查看它来立即弄清楚单元测试的测试内容。
答案 5 :(得分:1)
一个单元测试应该测试一件事,你应该避免单元测试中的逻辑,以避免编写测试单元测试的代码。
话虽如此,如果这200行中的大多数是设置代码以确保数据的特定状态以重现难以测试的边缘案例错误,那么这可能是唯一的方法。< / p>
但是,如果可能的话,你应该尽量减少单元测试中的行数。当它们很长时,它们很快变得非常脆弱(在修改时容易断裂)。