2013-08-30 29 views
3

我正在尝试做TDD的权利!我正在阅读有关TDD Inside Out的内容,而不是Outside In。原因是我不知道前面的图层如何,所以我的想法是开始编写测试,让它失败,然后开始编写我的第一层。TDD内外:查询如何正确地做到这一点?

在编写我的第一层时,我注意到我需要另一个层,我们称之为服务层。这是我感到困惑的地方,我在这里做什么?

我是否停止并创建一个失败的新测试,以便我可以使用TDD实现我的新服务层?完成后,我回到我的原始图层,我应该在这里创建一个服务层模拟?或者使用我刚刚通过TDD创建的服务层?

这是TDD对不对?所以如果我嘲笑事情,那么也许我的TDD不会推动我的发展?但是当然,如​​果我不嘲笑事情,这些技术上不是单元测试,而是更多集成测试?

如果确实我的单元测试(通过TDD编写)使用模拟,那么我需要一些其他类型的测试来测试每个单独层的集成为一个单元?

集成测试还是e2e测试?

我认为我的问题基本上是当我需要引入新图层时,我应该嘲笑这些图层吗?是否应该创建一个新测试来推动这个新图层的开发?

我希望有人能帮我解开这个混乱,我有我自己!

谢谢

回答

1

在开发TDD风格时,应该尽可能使用接口。

单元测试意味着你测试每个单元与大多数(理想的是所有)其他代码隔离。

所以在你的情况下:如果你当前的代码需要调用某个服务层。然后jsut为新模块创建一个接口并模拟它们的正确行为(或者如果您想测试错误处理,则预期会出现错误行为)。

...并把您的待办事项清单上测试新的服务层)

这样你集中你目前的单位对你的工作和有准备的接口为您服务层,当你开始这方面的工作。

如果你想测试你的图层如何协同工作,你需要某种集成测试。

+0

嗨马可,太棒了,是的,我总是试着对接口进行编程。所以在创建我现有的图层时,我快速地创建了一个接口,只用“ONLY”这个现有图层所需的方法,然后将其模拟出来。所以待办事项列表:-)一旦我完成了我现有图层的测试,我就会攻击它?这当然需要自己的单元测试写TDD方法? – Martin

+0

哦,回到我原来的问题,想象一下,现在我已经完成了所有的单元测试,它们都被嘲笑出来,实际的实现也运行良好,但是我没有“集成”测试来测试它们,你认为这个很重要 ?我知道它的工作的唯一方法就是通过运行我的应用程序。 – Martin

+0

运行该应用程序目前是我的测试方式,即所有内容都可以一起工作。只是没有花时间,想了解如何创建可靠的集成或系统测试 –

4

随着更多的经验,你会变得更好。 但现在让我说这个。首先,将TDD看作设计干净代码的工具(检查Uncle Bob's Clean Code以获得更多见解)。绝不会取代任何系统设计工作。这意味着你必须知道你想要什么类来设计(至少粗略的),你也必须定义这些类之间的接口。

其次,根据Mike Cohn - Working Effectively with Legacy Code - Chapter 2单元测试是不检查:

  1. 谈话到数据库
  2. communiating翻过网络
  3. 触摸文件系统
  4. 要求你做特别的事情与您的环境运行。

所以,你应该在单元测试的范围内。

一般来说,你想为每个组件(或类)编写单元测试。这意味着你为每个接口创建假类或模拟,例如为您的每个服务层类。这意味着你必须知道每个呼叫需要的确切接口(方法参数和返回值)。 尝试尽可能获得一个实例,然后转到下一个实例。

如果您不确定设计的外观,请考虑构建一个未经测试的原型。就像代码一样,您可以看到组件一起工作并帮助构建您的界面。然后勾画出设计,丢弃原型并用TDD方法重新开始。

相关问题