单元测试中的“坏”属性是什么？

我刚刚读了question，它回答了单元测试所需的特性，但应该避免什么？什么使得单元测试“不好”？单元测试中的“坏”属性是什么？

什么是你见过的最差的单元测试？（例如，我记得有一位开发人员告诉我他曾经找到一个测试套件，它有很多方法，但完全没有任何断言）。

我特别感兴趣的是单元测试稍微有点微妙和具体的问题，假设你有一个测试套件能够快速运行并且覆盖范围很广，它仍然会有哪些问题？

来源

2010-10-12 Adrian Mouat

这是一个相当主观的问题 - 你确定它属于对堆栈溢出？ – 2010-10-12 11:14:52

我不认为这是主观的 - 大多数人似乎都认同哪些不好的代码。 – 2010-10-12 15:35:34

为了给出更多的背景知识，当我想给人们一个不好的单元测试的例子时，发现它比我想象的要难。提出好的（或合理的）测试的例子似乎更容易，可能因为例子往往必然是简洁的。 – 2010-10-12 15:40:27

最好的单元测试很容易阅读和理解。快速执行。测试特定的功能，重构和维护。

最糟糕的不是上述情况。

来源

2010-10-12 11:02:24

脆弱的测试通常会有一个不可接受的维护开销，这将导致测试不会更新，保持断开状态，并且由于它们与源代码不同步而不会运行。

脆弱测试通常依赖于文件系统，注册表项，数据库等......这些对于集成和系统测试都很好，但有时候我会发现测试使用这些属性进行伪装（拼写？）作为单元测试，这通常是个问题。

来源

2010-10-12 11:07:34

本着CW的精神，我知道这一天会派上用场。

你也没问具体的一个:)见下

@Test 
     public void testCheckForDuplicateCustomer() { 
      //List<CustomerSearch> customerInfo = null; 
      String customerName = null; 
      boolean status = false; 
      try { 
        status = custSearchService.checkForDuplicateCustomer(customerName); 

/*************/ MAGIC BEGINS HERE 
         if(status){ 
          assertEquals(true, status); 
         } else { 
          assertEquals(false, status); 
         } 
         /**************/ MAGIC ENDS HERE 
       } catch (Exception e) { 
         //fail(); 
       } 
      }

来源

2010-10-12 11:45:35 JoseK

这让我微笑，所以我upvoted。不过，我真的在寻找不一定是骨头但没有做出好的单元测试的代码示例。 – 2010-10-12 15:41:52