作为测试驱动开发“里外翻新”的方法——行为驱动开发，它强调根据业务行为展开测试，而且测试要在功能实现之前，业务行为测试驱动开发工作。柏林的同行最近发布了 NBehave ，虽然框架很简单，但为实施.NET 敏捷开发提供了一个新的方法参考。
BDD（ Behaviour Driven Developement ）最重要的基础概念是业务化的“Story”，缘于一个很显而易见的原因——“软件开发是要服务于业务需要的”，但实际项目中往往因为各种外部原因打扰我们对这个问题的关注，项目开发的很多时间被“浪费”在怎样完成令项目经理满意的各种报表上，或者像有点“走火入魔”趋势的测试驱动一样，每天忙于为每个类建立 Test Class，并且为每个方法、属性建立 Test Method。但实际上业务目标往往是粗颗粒度的，BDD 一个很重要的目标就是直接达成“需求到实现”的过渡，而并非“需求——概要设计——详细设计——实现”这个中规中矩的过程。在项目规模不是很大、“Story”不是很复杂的情况下，借助各种快速开发工具（Visual Studio.NET/Eclipse），BDD 可以作为敏捷开发的一个很好的方法选择。
NBehave 有几个关键词：Scenario、Story、World，它们强调了在何种应用情境下，根据业务应用的特点，会有怎样的产出，就是“输入 -> 输出”。在其 ATM 的示例中很好地演示了这个过程：
- 定义了一个应用领域“账户管理”。
- 该领域会有一个事件——用户提取现金。
- 这里有个前提（Given），用户的账户信息信息可以从信用卡中获取。
- 然后发生了一个业务行为——用户提取现金（响应就会触发对应的事件）。
- 这是会出现两种情形（Scenarios）——超支和没有超支良种情况。
- 最后产生了一个业务结果，账号里的余额情况。
这个过程看上去很直接，而且基本上就是一个完整的需求点的映射，但没有提及任何类方法，更没有提到抽象后对象间的继承关系，完全就是业务化的，考虑范围也仅仅在一个非常集中的业务领域之内。使用后最大的感觉借用广告一句广告词就是“Just do it”，开发工作就是把上面的那个过程用代码填空，最后通过测试验证。
但是开发一个项目而言，除了业务部分外，还有很大的技术框架部分，NBehave 虽好，不过用它完成 DAAB 那样的技术框架就成问题了。从某种程度上看，NBehave 不强调抽象，它考虑的就是“Then and there”怎么做。所以，如果是技术层面的开发，请尽量集成现有框架；业务层面尤其是最外层的业务功能开发，不妨考虑一下 BDD；联系它们两者的中间部分，就用领域实体来完成，至于领域实体用 XSD 方式还是 ORM 方式，视情况和个人喜好而定。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论