Java登錄單元測試 一種不好的做法

日志記錄是調(diào)試過程中不可避免的一部分。好吧，至少在現(xiàn)代高級編程語言和架構(gòu)中是這樣。這不是三十年前的事了，而是現(xiàn)在。有時我們跟蹤變量，雖然這樣做的很少。更多的時候我們只是將它們打印到控制臺。此外，我們不只是使用println控制臺打印或我們擁有的任何東西來打印它們；相反，我們將消息發(fā)送到日志框架，該框架處理控制臺或任何其他日志記錄目的地，如文件。這種框架的美妙之處在于我們不需要在調(diào)試完成后刪除日志——我們只需配置框架以抑制生產(chǎn)環(huán)境中的所有調(diào)試級別的消息。一些日志記錄可能發(fā)生在單元測試中，我們是否也把它們留下或者不留下？

這是一個示例（它是對?CalcTest.java? 中來自?Polystat?的真實單元測試的簡化，?Polystat?是我們目前正在研究的靜態(tài)分析器）：

import com.jcabi.log.Logger;
import com.jcabi.xml.XML;
import org.hamcrest.MatcherAssert;
import org.hamcrest.Matchers;
import org.junit.jupiter.api.Test;
public final class FooTest {
  @Test
  public void buildsSimpleXml() {
    final XML xml = new Foo().build();
    Logger.debug(this, "This is the XML:\n%s", xml.toString());
    MatcherAssert.assertThat(
      xml,
      Matchers.notNullValue()
    );
  }
}

這是 Java，我將?JUnit5 + Hamcrest?與我自己的日志記錄框架?jcabi-log?一起使用，它是?Slf4j?的裝飾器，使用?Log4j?打印到控制臺。

這里發(fā)生了什么？有一個Foo帶有方法的類build()，它生成一個 XML 文檔（我使用的是?jcabi-xml?庫，它是?JDK DOM?的裝飾器）。然后，單元測試將 XML 文檔的內(nèi)容打印到控制臺并做出一個非常愚蠢的斷言：文檔不是 NULL。這很愚蠢，因為如果它是 NULL，那么日志語句在?.toString()?調(diào)用時就會失敗。

我是這段代碼的開發(fā)者，所以我知道發(fā)生了什么：我懶得寫一個正確的斷言，它會查看 XML 文檔并確保里面有正確的元素。我只是將它打印到控制臺，目視確認(rèn)其有效性并稱其為一天。如果我有更多的時間，這就是我編寫更好的單元測試的方式（我剛剛對 Polystat 測試進(jìn)行了改進(jìn)）：

import com.jcabi.matchers.XhtmlMatchers;
import org.hamcrest.MatcherAssert;
import org.junit.jupiter.api.Test;
public final class FooTest {
  @Test
  public void buildsSimpleXml() {
    MatcherAssert.assertThat(
      XhtmlMatchers.xhtml(new Foo().build()),
      XhtmlMatchers.hasXPath("http://foo")
    );
  }
}

現(xiàn)在，構(gòu)建了 XML 文檔，然后測試其中是否存在?//foo XPath?。只有在斷言失敗的情況下，才會將文檔的內(nèi)容打印到控制臺。如果 XML 具有所需的 XPath，則不會有控制臺輸出，這對未來的開發(fā)人員意味著沒有噪音。

此外，現(xiàn)在它是一個單語句測試，這本身就是一種很好的做法。

回顧我測試和記錄的經(jīng)驗，我認(rèn)為記錄單元測試是一個壞主意。有時不可避免，因為我們懶惰或根本沒有足夠的時間，但仍然很糟糕。日志記錄幫助我們在視覺上確認(rèn)輸出的正確性，但它從項目中帶走了這些知識。那些將在稍后進(jìn)行測試的人不會知道我們在那里看到了什么。他們會在控制臺看到輸出，但不知道它是否仍然符合我在撰寫本文時的期望。

我會說單元測試中的每個日志記錄行都是來自其作者的消息：“我對我現(xiàn)在看到的數(shù)據(jù)有所了解，但我懶得告訴你，你只需要相信我好的?！?/p>

我建議我們不要在我們的代碼中留下這樣的消息。