对于手工联调这种费时费力的工作能少做就少做，能自动化就自动化，搞软件的生命短暂，浪费在这上不值。一天的时间很快就过去了时间点远的开发就领新stori等另一端开发完，对于联调时间点近的开发人员会等一等。已经若干天过去了总觉得其中有什么问题，但是说不出来。上周去QCon听了韩老师的分享，突然发现这种联调在以前团队的也是有的只不过我解决方式不一样，所以问题没有这么突出。

现在软件开发，发生问题的原因很简单。因为系统复杂性提升，模块拆分也很普遍，很难形成一个团队做端到端交付，没有任何外部依赖。典型场景是模块A由一个团队1开发，模块B由团队2开发。这时，团队A功能开发完成后必需要和团队B开发的相应功能联调。目的走一个端到端的流程，确认功能正确。

很难做到同一功能在两个模块上同时开发完成，团队1和团队2开发计划多是独立制定。之间没有任何等待。开发快的要等开发慢的一方的stori虽然开发完了但不能进入测试，延长了交付时间。

已经过去一两天甚至更久，等测试发现bug时。开发在做其他功能。回来解决问题，又要上下文切换，再度浪费时间。定位问题还需要花一番功夫。同时联调发生问题时。开发流程图之前的项目中我使用一种契约测试(ContractTest方法来解决这个问题。

两个团队确定接口具体格式，首先。这组格式就相当于一组契约，而后两个团队根据这个契约开发各自功能。作为消费方的团队1为这个接口添加一组自动化测试，同时。确保模块B功能符合契约。每次模块B代码改动都会触发这组测试，测试通过时意味着生产者为消费者提供了正确的功能，反之不能。这样模块B改动肯定不会影响模块A即便有影响，也可以通过测试在第一时间反映进去。

契约测试节省了开发人员的联调时间，这种方法。QA 直接测试端到端的功能。同时遇到问题时也很容易定位问题发生根源。着眼点在确保模块外部依赖的正确性。有了这层保障，这种测试与模块A自身的单元测试不同。模块A单元测试就可以使用TestDoublFakeMock等)构造出更关注于自身逻辑的测试集，提高测试的运行速度和稳定性。

一定要由消费者来写，谁来写测试 -这个回答相对简单。这样才干确保测试代码和产品代码采用相同的调用方式。放在消费者端，如何组织测试 -有两种方式可以选择。每个消费者维护自己的一套测试；或放在生产者一端，每个模块维护一套针对本模块的测试。第一种方式更容易引起相关消费者团队的重视，针对性更强，但会引入一定的代码重复，第二种正相反。为了更快更有针对性的发现问题，所在团队使用了第一种方法。