由 dawei 而随着项目的迭代，产品功能不断增加，项目会变得越来越复杂。在后期，每修改增加的功能相对上一版本已存在功能的比例却是越来越小。但每一次或大或小的版本升级,我们都需要保证新增或修改的功能不影响上一版本已存在的功能。但要达到这一点却是困难异常，哪怕只改了一行代码、哪怕这项更改由非常优秀的开发者完成，我们都很难保证这项功能对上一版本的功能无任何影响。
要保证每次上线的安全，我们需要开发和测试完成两项工作。一是，开发者在增加或变动某项新功能后，补充相应的测试用例，但写过单元测试的同学都知道，完成一个单元测试用例所花费的时间可能比完成相应功能花费的时间更多得多。
大多情况只能写几个核心的测试用例，而在人员不足，时间紧张的情况下，则更是难上加难了。在后期，因为功能在不断增加，回归测试的工作量越来越大，同时因为是回归，可能几百甚至上千用例中才会发现一个问题，甚至一个问题也没有，测试投入工作的时间与最终的收益不成比例。
另外测试人员对相同内容的重复测试，会有一种疲惫感，这样一来会给测试人员带来消极情绪，当真的有问题(尤其是较复杂的数据问题)发生时，也可能会因为这种疲惫而将问题忽略(如果一个用例测了10遍都没问题,第11遍测的时候心里可能会默认这个地方是没问题的了)。这时候有些测试人员可能会考虑做自动化测试，但是自动化测试前期投入的成本较高，另外对测试人员的要求较高。如果项目变动比较频繁，部分自动化测试可能需要重新设计，会带来较高的成本。
而Diffy为上述问题提供了较好的解决方案，不同于我们常用的其他测试工具或框架从代码或接口的返回结果的正确性去验证，而是如其名：通过代码的差异去验证测试。
需要注意的是：既然是差异，那至少是两者之间比较才有差异，对于第一行代码或新增的功能无法比较，自然也就无法验证，这时diffy无法发挥作用。但在后续增加修改,项目不停迭代的周期中，diffy就可以发挥它的舞台了，有了上一版本以及测试人员在上一版本测试工作的基础，我们就通过上一版本和当前版本比较差异了。