你能产生多少不同的测试用例，让你觉得你已经充分测试了一个

读取三个整数值和将其解释为表示三角形边的长度。打印一条信息，说明三角形是不等边的、等腰的还是等边的。

Binder的TOOS中的这个练习改编自Myers的《软件测试的艺术》。如果你是典型的，你在这个测试中做得很差。

什么是单元测试？

单元测试是软件开发的一种方法。ABAP单元测试是开发人员工具箱中一个成熟的框架。

一方面，重点是：用户验收测试验证可以在多个系统中实现的行为。集成测试可以看作是对独立系统（如服务器（主数据或SQL数据库）和客户机系统）交互的验证。当关注单个系统时，我们验证最终用户看到的行为。这通常需要过程知识，理想情况下不应由原始开发人员执行以减少偏差。测试人员可能理解系统架构，但软件实现的细节通常被视为一个黑匣子。集成或用户验收测试也可以使用单元测试框架创建，但其他工具更适合（例如eCATT）。另一方面，单元测试是白盒或灰盒测试，在白盒或灰盒测试中，对系统设计的良好理解用于隔离地测试模块。这通常是开发人员使用的单元测试框架。我们关注的是那些只能由开发人员创建的单元测试，因此在软件生命周期管理的开发阶段之外，这些测试是不可见的。或者不要。

在ABAP中采用

ABAP单元框架在ABAP工作台中可以被视为异类。它相对较晚地与面向对象技术的后期采用联系在一起，市场上解释了如何通过单独测试程序例程来帮助生成更健壮的代码。在这样一个环境中，即使是冒烟测试也需要理解与数据库的集成，这并没有产生积极的共鸣。

冒烟测试=启动应用程序并检查它是否在火焰中崩溃。

ABAP开发中的一个特殊要求是充分理解业务规则和数据库表，以便创建有意义的测试。SAP的卖点是业务流程，而不是开发语言。

另一方面，工具链的多样化迫使人们理解并有时采用敏捷流程。实用主义的ABAP开发人员将允许对任何为自己付费的新技术产生积极的惊喜。我假设大多数开发人员都尝试过，但发现在这种情况下还不值得这么麻烦。

在本博客的其余部分，我将通过介绍我对投资测试套件所需的思维过程的看法来尝试管理预期。我将在ABAP上下文中讨论单元测试的价值和限制，并介绍一些由ABAP单元帮助的重构用例。单元测试应该很简单。复杂的过程导致复杂的测试。如果你花更多的时间来修复测试，而不是修复代码，那么测试是没有用的

编写单元测试是困难的：不，设计是困难的。有可能，如果你的测试很难写，那么你试图一次测试太多，什么是数据中台，因为你的设计不干净。尝试编写更简单的单元测试会迫使您在编写测试之前分离依赖项。这在你的软件中已经是一个很大的变化。

你应该先创建测试，云服务器的，然后创建产品代码。虽然这是可能的，但这很难。我还没有看到它在ABAP环境下做得很好。这种方法被称为测试引导的增长软件（参见参考资料）。

你应该有100%的代码覆盖率。为什么？测试到位并不能保证没有错误。它们有助于识别缺少测试的代码区域。这是唯一的质量衡量标准。

那你为什么要进行单元测试呢？

我正在测试以验证我的代码是否完全按照我的预期执行。我不希望对代码或测试行为感到惊讶。我将test作为一个规范来编写：确认这个模块在使用定义的参数调用时是否执行了预期的操作。在本文中，单元测试是以后的保险单，我将在重构时更改代码。我们的计划不是现在就发现错误。如果我发现一个错误，我会添加一个单元测试来确认修复后的行为是否符合预期。

这意味着我的策略是在代码实现后进行测试。

先测试有一个问题，即在代码实现之前创建测试：这需要很多规则。在进行下一步之前，实现使测试通过所需的最小值比您想象的要困难得多。在一个集成的环境中，可能不可能有大量的现有代码库需要修改以满足新的要求行为。

我不希望每个人都这样做，个人用云服务器，但我肯定认为每个人都可以最后测试。

最后测试的问题是初学者会花很多精力来编写集成测试，而不是单元测试。集成测试是大而脆弱的，它们很容易被破坏，并且必须在代码库中进行小的更改来纠正。它们很难被支持，而且常常被抛弃，因为不停地处理测试套件而不是修复错误和重构产品代码没有任何好处。

无意义的单元测试