JUnit 单元测试小结

    阅读了一些有关单元测试的文章，从这些文章中截取了一些信息，算是在学习过程中的一个小结吧！备日后查看！

    单元测试代码不是用来证明您是对的，而是为了证明您没有错。因此单元测试的范围要全面，比如对边界值、正常值、错误值得测试；对代码可能出现的问题要全面预测，而这也正是需求分析、详细设计环节中要考虑的。
   请牢记这一条 JUnit 最佳实践：测试任何可能的错误。单元测试不是用来证明您是对的，而是为了证明您没有错。

    JUnit 将测试失败的情况分为两种：failure 和 error。Failure 一般由单元测试使用的断言方法判断失败引起，它表示在测试点发现了问题；而 error 则是由代码异常引起，这是测试目的之外的发现，它可能产生于测试代码本身的错误（测试代码也是代码，同样无法保证完全没有缺陷），也可能是被测试代码中的一个隐藏的bug。


JUnit的几个基本的概念：TestCase，TestSuite，TestFixtrue

  TestCase: 代表一个测试用例，每一个TestCase实例都对应一个测试,这个测试通过这个TestCase实例的名字标志，以便在测试结果中指明哪

个测试出现了问题.TestCase继承自Assert,因此可以实现各种断言。
  TestSuite：代表需要测试的一组测试用例，也就是测试用例的集合，
  TestFixtrue：代表一个测试环境。它用于组合一组测试用例，这组测试用例需要共同的测试运行环境。

  Test接口: 代表一个测试。它是框架的主接口有两个方法：
         int countTestCases();//返回所有测试用例的个数。
            void run(TestResult result);//运行一个测试，并且收集运行结果到TestResult.

  TestCase类: TestCase实现了Test接口，是框架提供的供我们继承的类，我们的所有的测试方法都需要在TestCase的子类中定义，并且符合

特定的设计协议。一个TestCase实例代表一个具体的测试实例，对应一个对某一方法或概念的测试。每个TestCase实例都有一个名字。一个

TestCase类却定义了一个TestFixture。具体的说就是我们自己定义的TestCase子类中可以定义很多的public 没有参数的 testxxx方法。运行

时，每个testxxx都在自己的fixture中运行。每个运行的TestCase都有一个名字，如果不指定，一般是TestCase中定义的test方法的名字。
 
  TestSuite类: 和TestCase一样TestSuite也实现了Test接口。一个TestSuite可以包含一系列的TestCase。把testCase组装入TestSuite有几

种方式：
   A，通过将TestCase的Class参数传入TestSuite的构造函数，TestSuite会自动收集TestCase中所有的public的没有参数的testxxx方法加入

TestSuite中。
   B，构造空的TestSuite后通过void addTest(Test test)方法添加测试。
   C：构造空的TestSuite后通过void addTestSuite(Class testClass) 方法添加测试集。

   打算把单元测试代码放在什么地方呢？
   把它和被测试代码混在一起，这显然会照成混乱，因为单元测试代码是不会出现在最终产品中的。建议您分别为单元测试代码与被测试代码创建单独的目录，并保证测试代码和被测试代码使用相同的包名。这样既保证了代码的分离，同时还保证了查找的方便。

  
    关于setup与teardown
a)不要用TestCase的构造函数初始化Fixture，而要用setUp()和tearDown()方法。
b)在setUp和tearDown中的代码不应该是与测试方法相关的，而应该是全局相关的。如：针对与测试方法都要用到的数据库链接等等。
c)当继承一个测试类时，记得调用父类的setUp()和tearDown()方法。