经过几年后的坏习惯在我工作的地方，从“建筑师”传世认为必须有一个更好的办法的，我最近一直在读周围TDD和DDD，我认为原则和做法将是一个非常适合为我们写的软件的复杂性。
然而，许多TDD样品我看到调用域对象的一个方法，然后测试对象的属性，以确保正确地执行的行为。
在另一方面，在行业内推崇的几个人（Greg Young的最显着这么与他会谈CQRS）主张完全清除所有的“干将”封装每个域对象。
因此，我的问题是：一个人如何测试一个域对象的功能，如果它被禁止检索其状态？
我相信我失去了一些东西根本所以请随时给我打电话白痴和赐教 - 任何指导，将不胜感激。
什么你所描述的状态验证 ，其中您断言的域对象的状态。 还有那个叫利用Mock对象动作验证 TDD的一个分支。
行为验证，您可以指定哪些方法应该被调用，如果你想，该方法是不叫。
看看这篇文章由Martin Fowler了解更多详情： 模拟的功能没有存根 。
OK，这个答案为一年，太迟了;-)
但是，当你想测试CQRS模式，你可以在发射域事件，而不是在实体状态断言断言。
例如，如果你想测试，如果调用：customer.Rename（“富”）获得了正确的行为。
如果customer.Name等于“foo”测试取而代之的，你作测试是否有与你当前事件存储值“富”挂起CustomerRename事件。 （在你的UOW或在实体事件列表取决于实现）
如果你真的要去尽可能禁止状态的恢复，那么你将被限制在行为测试，可能是通过一个模拟框架，如TypeMock，这也在跟踪对象的行为的权力。 如果你能做到纯粹的BDD，那么理论上你可以通过它的行为方式维护你的整个系统的正确性。
在实践中，我发现BDD是在很多情况下不仅仅是状态的测试更脆。 虽然有些人可能需要进行一定的理论，它只是它是否适合你的作品。 基于状态的测试仍然占90％的我们写的所有的单元测试，而且我们对我们的团队非常了解BDD的。
做什么工作最适合你。
一对夫妇的事情。
首先，当你做这样的事情TDD使你的代码可测试你结束了较小的类。 如果你有很多，你不能检查私人性质的一类，那里有一个很好的机会，它可能被分成多个类和更加可测试。
其次，老校友OO架构试图把软件安全使用的语言保障措施，以防止事情被访问。 一个TDD的架构使软件更强大的通过编写验证了代码实际上做试验，把不太注重运用语言结构，以确保什么程序没有做。
最后，检查属性不验证码做了它应该做的唯一途径。 这本书的xUnit设计模式文档的其他方法在这里： http://xunitpatterns.com/Result%20Verification%20Patterns.html
我调用系统的公共输入法（即我把数据输入到系统中），然后我得到（并断言）系统的输出。 我没有测试系统的内部状态，而是它的公共/可见的行为： 如果一个测试内部实现，或只测试公众的行为？
所谓国家检测你提到是什么。 还有行为测试。 用于该技术是依赖注入，反转控制和嘲讽：
你的类的所有副作用实现其“依赖”的方法调用 - 从外部提供，通常是在构造函数，即对象。 然后，在你的单元测试，你提供一个假的对象，而不是一个真实的。 如果某些方法被称为假的对象能记住，这是你在你的测试断言什么。
存在惩戒，通过动态地生成实现给定的接口的类自动模拟对象创建框架的数量。 最流行的是Rhino.Mocks和起订量。
嘿贾斯汀，和你一样，我最近想加入干将我只写域对象进行单元测试的缘故，但现在我相信我错了。 假设你已经买成在第一时间只写域的想法，那么如果你有干将可言，你是在自找麻烦。 只写域原则会要你从你的域对象触发事件，或者从一个投影，你的域对象写，或类似的东西读。 一旦你公开你开始揭露对象的“形”干将，并作为Greg Young的说，“域对象具有行为，而不是形”。
话虽这么说，我与你同样的问题挣扎......你怎么了单元测试只写域对象？ 这是我目前的计划：我想使我的域对象火域事件说：“这些属性改变”，而在我的单元测试，我会为它之前，我发送“EditCommand”注册。 退房乌迪大汉的上域事件后在这里 ，也看到什么埃里克·埃文斯说，关于域事件 。
我想知道同样的事情，直到我终于在以下文章跌跌撞撞。 我发现他们的行为进行核查，特别是第一个给我提供几个“啊哈时刻”是伟大的引物：
