你会发现这些测试类和被测试类很快会失去其联系。在BDD中，不仅仅测试方法不再是testXXX，那些测试类也可能不再是按约定取的名称。或者，你可能针对同一个被测试类/方法，会拥有多个测试的方法。例如之前的那个例子，当然不是很贴切，可能一个具体的测试类，比如来测试getHolder方法的行为的测试类更好一点。

　　你需要帮助吗?这是我的新的项目TestedBy

　　通过注释来标注被测试类和方法，来使其与测试类和方法联系在一起，怎么样?不是太坏，你说呢?

　　我的想法或多或少从这里开始，但是不于一个注释。我很高兴这个主意，因此我决定开始一个新的开源项目来提供测试工具，用来把被测试类放到中心的位置。

　　继续看，我将展示给你如何通过注释和相关工具来改变你测试的方法。

　　TestedBy目标在于改变观察测试类和被测试类的角度。我们可以把被测试的类(项目中重要的类)放在中心位置，并可从这些类连接到他们的测试类和方法。一个代码快照可能抵得上更多的解释：

　　Java代码

1. public class TestedBySample {

　　2.

　　3. /**

　　4. * @param args

　　5. */

　　6. public static void main( String[] args ) {

　　7. TestedBySample sample = new TestedBySample();

　　8. System.out.print(sample.add(1， 2));

　　9.

　　10. }

　　11.

　　12. @TestedBy( testClass = "it.javalinux.testedby.TestedBySampleTest"， testMethod = "addShouldWork" )

　　13. public int add( int i，

　　14. int j ) {

　　15. return i + j;

　　16. }

　　17. @TestedByList( {@TestedBy( testClass = "it.javalinux.testedby.TestedBySampleTest"， testMethod = "addShouldWork" )，

　　18. @TestedBy( testClass = "it.javalinux.testedby.TestedBySampleTest"， testMethod = "addShouldWork2" )} )

　　19. public int add2( int i，

　　20. int j ) {

　　21. return i + j;

　　22. }

　　23.

　　24. }
　　很好吧，但是它确实改变了你单元测试的方法?我觉得是，怎么样，至少在两个方面。
1、通过接口和约束来设计Design by interface and contracts

　　软件设计中的词语说“Design by interface”，仍然在我耳边响起。因此你也当然可以“Test interface”。

　　很多正式的“Design by interface”意味着定义好你的接口，并且接着实现它们(可能大部分时间是由不同的人或者公司来实现)。总之，你能够影响到的只是如一个强类型语言，例如java能为你提供的那样：一个接口的实现必须遵循接口的签名，类型和参数变量保持一致。你不能控制到那些具体的行为。当然，这也是一个API设计上的一个很大的局限性，因为可能导致实现完全不可预期的行为。

　　这里我引出Eiffell language 和他的 design by contract (DbC)方法，约定来引导继承过来的特征的重新定义。在java中有很多工具支持Dbc，但是我的想法是我们已经有一个很强大的方式来测试方法上的约束，并且使用更少的代码来清楚行为：Unit Tests单元测试。

　　使用TestedBy，测试在接口(或者父类)上声明，所有实现类都能运行这些测试，来验证这些实现类的行为，是符合父类类型上的行为和约束定义的。API设计者不仅提供接口，