单元测试简介

    这段时间除了项目本身的事情外,可以说把全部的时间都放在”敏捷”的学习上了,要想理解敏捷,单元测试是必不可少的(其实需要了解的东西很多)。所以我把这个学习的过程记下来。不管以后学得如何，都可以回过头来看看。

     单元测试和我们平时说的测试是有很大不同的，他强调的是单元，而不是整体。强调的是每一个功能都可以正确的执行，而不是性能的优劣。等等。

    单元测试的思想是给一个要测试的方法提供很多测试用例，看看方法在各种情况下是否都可以正确的执行。而且可以确保软件每完成的一个功能都是正确的。在传统意义上的测试是这样的：我们把软件开发完毕，写一个程序可以正确执行的测试用例，运行这个测试用例，如果通过了，就认为我们的程序可以提交用户了，如果没有通过，就只能根据错误日志在系统中找错误。这种传统的做法是有很大的弊端的，比如说系统不可能只按一种情况运行，系统在运行过程中可能会由于用户的疏忽得到错误的输入而是系统崩溃，也可能会由于网络不通，内存益处等问题导致系统崩溃，所以我们不能只写一种测试用例，但如果把每一种情况都考虑到，我想也是不现实的。那么单元测试为我们提供了可能性，为每个方法写各种测试用例比起为整个系统写所有的测试用例要容易的多（当然，这也取决与程序员的经验）。而且如果我们边开发系统，边写单元测试，在系统完成后，我们就有了一个全面的测试用例，当某种新情况使测试失败时，我们可以定位到哪个方法，从而很快的解决问题。

    编写单元测试还有一个好处，就是可以使你的系统高度的松偶合，方便测试，想想如果一个系统的表示层，业务层和数据层都混合在一起，那么测试起来估计只能人为的通过手工操作界面进行测试了，我想这应该是最原始和低效的方法了，现在的发展速度是不允许我们这样的。如果我们一开始就考虑到要做单元测试，那么我们就会把我们的系统做成方便测试的，从而是表示层和业务层就脱离了，这样在整体测试是也方便编写测试用例，而不用手工操作界面了。

    说了这么多单元测试的好处，我想肯定还有很多其他的好处，希望大家告诉我。