作为一名软件开发人员，自动化测试已经成为我职业生涯中的一个重要部分。但是，您不能总是避免要测试的单个方法的外部依赖性。你的依赖性越多，测试就越麻烦。

你也可以阅读开始编写单元测试的例子来了解我是如何进行这种测试的。

让我告诉你我是如何随着时间的推移改变了我的测试设计来处理这个问题的。我真的很想在评论中听听你的意见！

标准建议是模拟被测试代码调用的任何逻辑。

因此，假设这样的应用程序需要测试：

当每个类单独测试时，云信息，必须为类所依赖的所有代码编写模拟逻辑。这导致实现了大量的测试编码：

这种设计中的测试通常是指用户看不见的行为，但是"隐藏"（一个类如何干扰其他类）。

尽管上面的简化图没有显示测试编码本身的任何框，但我们已经有了很多框。这种设计中的测试可能很难理解。另一方面，这些测试的任务之一正是为了让您在稍后返回测试代码进行一些修改时能够更好地理解这些代码。

那么为什么不编写一个单元测试呢？

需要的测试编码要少得多。这些测试也可能更容易阅读，因为它们可能与原始用户需求更相关。因此，我使用绿色作为测试编码。

是的，在这个简单的例子中，大数据主要学什么，它看起来像一个集成测试。尤其是在更复杂的软件中，淘客程序，通过自动化集成测试覆盖更广泛的功能领域，而不是过于关注应用程序的单个部分，确实是有意义的。最终，您将获得代码单元"适当大小"的测试（相对于您的需求），而不是被迫将本地测试类与每个生产代码类隔离开来。

早在很多年前，Robert C.Martin（Bob叔叔）的Clean code initiative就试图最小化代码复杂性。SAP的ABAP编程指南也包含了很多有用的建议，但是2009年的原始版本几乎没有涉及到测试。我的印象是，干净的代码比自动测试更受欢迎。

现在我的日常工作是处理BW系统中的ABAP，有时还处理SAP BW转换、规划功能和其他高级"编码"。

我在2013年编写了我的第一个自动测试，只为一个复杂的函数计算人力资源报告应用程序的天数。我可以做这个测试，因为这个函数几乎没有依赖于其他代码。应用程序的其余部分仍然没有自动测试，因为我不知道如何处理依赖关系。

即使几年后我学会了在测试中处理外部依赖关系，我的测试覆盖率仍然停留在代码的5%左右，因为添加模拟逻辑（无论是通过继承还是通过接口）对我来说太费劲了。

当我从2016年开始能够使用ABAP测试接缝时，情况发生了变化。Test seam是SAP ABAP的特殊语句，用于在自动测试期间处理依赖关系。它们有一些限制，但好的一点是，它们很容易使用。因此，使用测试接缝很容易添加自动测试，即使依赖关系使测试变得困难。这彻底改变了我的处境。在此之前，我很少写自动测试，因为我觉得我真的需要它们。有了测试缝，再也没有借口了。我的新座右铭是："糟糕的考试总比没有考试好"

我大大提高了我的考试覆盖率。当我需要修改现有代码时，我经常添加测试。与传统技术相比，测试接缝的风险更小，成本更低。Test seams还可以很好地处理遗留的ABAP代码，这些代码不包含容易被模仿的接口或类。

2018年，我读了这条tweet…

Ian Cooper讲述了他在自动测试方面的经验以及他犯下的所有错误。这是一个很好的介绍，看看你自己！

他建议阅读Kent Beck关于测试驱动设计的原著。在他的概念中，关于单元测试的思想不是测试单个类，而是测试要测试的代码的适当大小。不要太小也不要太大。这可能是一个单独的类，但也可能是一个不同大小的单元。

所以在看了这个演示之后，何为大数据，我再次改变了may的测试风格。

我只在发现有必要的时候才尝试去模仿。在所有其他情况下，我从数据库（在开发系统中）读写。有时我能够将测试数据与其他数据分开。但这通常是不可能的。所以尽管如此，我还是接受了因为有人改变了数据而导致测试中断的风险。事实上，这种情况有时会发生，但不是经常发生的。作为一个好处，我需要更少的模拟编码和更少的测试接缝。

Ian Cooper还建议，测试驱动设计意味着：

考虑到这一点，编写自动化测试感觉更加简单。在许多情况下，我根本不需要模拟逻辑。

当然，企业应用管理，测试仍然意味着一些努力。对于每一个新的应用程序，你必须考虑如何才能很好地测试它。