我的单元测试认识之路(下)
进入新公司之后，开发方式跟以前相比变化很大。以前公司做的项目基本上没有什么文档，只有一系列的用户需求，然后根据需求来决定该怎么做，做成怎么样。但
在这里，动手之前首先需要准备User Story，即虚拟出最终用户的操作，写成文档来决定我们应该如何做，怎么去做。
最初，我是根据User Story的定义来定义好接口，然后根据接口编写Unit Test，最后去实现然后测试。当User Story并不是很复杂的时候，这种方法的确不错。然而，当你所要做的某些方法很复杂，需要考虑很多情况的时候，你会发现你的测试和实现可能会将你的代码 弄的一团糟，因为你要注意的地方太多了！
那么，这个时候，为什么不让我们的测试跟着我们定的User Story来走呢？
举个例子：有一个系统需要经常性的和服务器同步，那么对于第一次同步和以后同步肯定会有所差别。正常情况下我们很难去写一个测试直接去测试你的方法的所有 方面。但是如果根据User Story来编写测试呢？比如这里我们编写FirstSynchTest来测试第一次同步该做什么，SecondSynchTest来测试第二次同步该做 什么。这样，对于每次，我们只需要集中精力解决第一次我们要实现方法的某些功能，然后在第二次需要的时候再去考虑其他情况，但同时只要去保证第一次的测试 通过便可以了。
这样来做还有一个好处就是User Story和Unit Test是一个相互迭代的过程，在我们编写Unit Test的时候，也同时是对User Story的一种检查，因为Unit Test的编写直接去参考所编写的User Story。通常情况下对于我们开发人员只能给出一个我们认为用户该怎么做的步骤，并且很多时候，我们会遗漏一些简单的步骤。但在编写Unit Test的时候发现User Story是跳跃式的，于是回头添加User Story，然后继续更新Unit Test。
上面的方式最典型的一个例子就是在产品的升级中：最初做好的产品可能用户希望我们添加一些新的特性进去，但是这些特性会分散到用户操作的各个环节中。如果 按照User Story来编写的Unit Test，那么我们只需要回到特定的地方，加入新特性的Test，然后实现并测试，这样是不是觉得很直观呢？
总的来说这篇东西写的很枯燥，因为要将自己的一些体会写出来真的是很难。因为很多时候都是噢的一声，自己恍然大悟了，但是让你说出来却未必说的清楚。如果你觉得我的这种想法很危险，欢迎给我提出来
最初，我是根据User Story的定义来定义好接口，然后根据接口编写Unit Test，最后去实现然后测试。当User Story并不是很复杂的时候，这种方法的确不错。然而，当你所要做的某些方法很复杂，需要考虑很多情况的时候，你会发现你的测试和实现可能会将你的代码 弄的一团糟，因为你要注意的地方太多了！
那么，这个时候，为什么不让我们的测试跟着我们定的User Story来走呢？
举个例子：有一个系统需要经常性的和服务器同步，那么对于第一次同步和以后同步肯定会有所差别。正常情况下我们很难去写一个测试直接去测试你的方法的所有 方面。但是如果根据User Story来编写测试呢？比如这里我们编写FirstSynchTest来测试第一次同步该做什么，SecondSynchTest来测试第二次同步该做 什么。这样，对于每次，我们只需要集中精力解决第一次我们要实现方法的某些功能，然后在第二次需要的时候再去考虑其他情况，但同时只要去保证第一次的测试 通过便可以了。
这样来做还有一个好处就是User Story和Unit Test是一个相互迭代的过程，在我们编写Unit Test的时候，也同时是对User Story的一种检查，因为Unit Test的编写直接去参考所编写的User Story。通常情况下对于我们开发人员只能给出一个我们认为用户该怎么做的步骤，并且很多时候，我们会遗漏一些简单的步骤。但在编写Unit Test的时候发现User Story是跳跃式的，于是回头添加User Story，然后继续更新Unit Test。
上面的方式最典型的一个例子就是在产品的升级中：最初做好的产品可能用户希望我们添加一些新的特性进去，但是这些特性会分散到用户操作的各个环节中。如果 按照User Story来编写的Unit Test，那么我们只需要回到特定的地方，加入新特性的Test，然后实现并测试，这样是不是觉得很直观呢？
总的来说这篇东西写的很枯燥，因为要将自己的一些体会写出来真的是很难。因为很多时候都是噢的一声，自己恍然大悟了，但是让你说出来却未必说的清楚。如果你觉得我的这种想法很危险，欢迎给我提出来
