对Cucumber的一些想法

今天看了一下Cucumber和Cuke4Nuke。前者是ruby社区流行的BDD框架，它使用一种叫做Gherkin的语言来描述story和scenario，然后使用ruby来实现这些scenario。而Cuke4Nuke则可以让你用.NET上的语言（比如C#）来编写scenario的实现部分。相比于在IronRuby下直接跑cucumber，你可以用熟悉的语言（C#）来写测试，也省去了在IronRuby中调用C#代码引入的额外复杂性。

抛开BDD的本来意图，这样将scenario实现为自动化测试的方式至少解决了几个问题：

1. 测试用例的可读性

目前，我在项目中使用xunit.net ＋ selenium来做website的functional test，即使使用page object pattern对selenium进行包装，仍然无法保证test case的可读性。因为代码包含了太多的技术细节，使得原本test case想要表达的意图淹没在代码之中。有两个方法可以部分解决这个问题，一个就是写注释，另一个就是用函数包装，但是这两种办法都是指标不止本。

而使用cucumber意味着你可以用业务领域的语言来表述test case或者叫scenario，这保证了每个人阅读的时候有一致的理解，维护的时候比较方便。

 

2. 区分自动和手动执行的测试用例

如果没有自动化测试，QA需要花费大量的时间做regression测试，随着功能越来越多，进行一次全面测试的时间也就越长。但是即使有了自动化测试，仍然很难保证所有的测试都能够被自动化，有些是因为自动化的代价太大，有些是因为我们还没有找到行之有效的测试手段。 因此QA需要维护一个测试用例文档，并且需要跟踪哪些测试用例已经被自动化了，哪些没有。这样在减少QA工作量的同时，不会有被遗漏的测试用例。不过在实际项目中，这样手工去维护一个excel之类的列表并不是一件容易的事，不仅需要花费大量的精力，还很容易出现错误。

使用cucumber的话，test case可以始终保持一种形态，就是scenario，而不是像现在这样分离为excel中的test case，以及代码中的test case。当scenario可以被执行的时候，哪些不能被执行也就一目了然了。

3. QA和Dev更好的合作

QA在Dev做story之前先把scenario写出来，Dev在做完stroy时，要保证测试能够通过。对于QA来说，可以用业务领域的语言来描述，简单而且直观。甚至也可以早早的就把scenario写出来，等到需要实现story的时候，只需要简单的将scenario移动到一个特定的地方，比如一个文件夹。那么这个scenario就将被包含在下一次的自动化测试中，可以保证Dev确实实现了这个测试。

 

以上只是初步想法，具体效果还有待真实项目的检验。