您好

有几种方法可以回答您的问题：

-检查代码：代码检查器（trans SCI）或更好的ATC（trans ATC）

-检查方法的输入/输出：Abap Unit（如果您对此很感兴趣，则可以顺序开发TDD：Test Drive Development）

如果可以的话，我可以给您简单的Abap Unit示例 您想要的

您对TDD的熟练程度有不同的水平，并且与"如何抽象问题并将其转化为可测试的体系结构"（可测试的设计）与您的熟练程度紧密相关。 ）。 在某个时候，您最终创建UML只是为了支持与他人进行设计交流。 但是，对我来说，它们始终是有效的，即使我在"完成"某件事后再做它们，我最终还是看到可以在"它"的整体设计中改进的事情。

我想指出Fred的测试有多么简单和强大。 它有两件事：

1）测试和实现彼此不了解。 这是规则*。 通过查看Fred是如何从"外部"测试其类功能的，您可以看到这一点。 您可以更改实施他的课程的方式，他的测试仍然有效，并告诉您是否到达那里。
*当然，每条规则都有例外，例如当您与其他事物有依赖关系时，您想确保以某种方式与该依赖关系进行交互。 这些被称为测试注入，您注入您的"间谍"，然后问这个间谍，他从内部看到了什么，您所期望的是什么？

2）再看一下它们有多简单！ 当然，我们的日常工作中有更复杂的要求，但是如果您尝试进行TDD，然后看起来变得凌乱，则需要大量的设置代码，需要进行大量的依赖模拟，那么，这表明您可能正在 试图在您的类上实现太多目标，您需要将其分为不同的"关注点"，可以抽象化的"关注点"，作为依赖项注入并更轻松地操纵"关注点"与测试对象的交互方式。

像往常一样，我确实有一个建议，使用代理类cl_abap_unit_assert并从中继承，这样您的测试代码可以变得更简洁：

 assert_equals（
        行为= o_cut-> count_diff_letters_in_word（`Aa BccBc`）
        exp = 5
        msg ="应该回复5个不同的字母"）。

如果需要，您可以复制此。

嗨

正如弗雷德里克（Frederic）所说，有很多答案。

通常，一种自定义代码测试方法有两种方式（我这样做

• 积极方法（涉及常规场景）-寻找预期结果
• 消极方法（不应该这样）

1. viz ..如果数据不完整怎么办，
2. 如果具有完整长度的值（查找截断），怎么办
3. 数字字段0（除以零） ）
4. 重复
5. 大数据量
6. 由于外部因素导致的转储的可能性
7. 权威和证券

致谢，Venkat

在我看来，代码审查并不是要检查程序是否达到了预期的目的。 而是要处理设计问题，以改进代码。 当我还是全球SAP实施中的重要经理时，我对项目进行了代码审查。 新手将审查专家-并学习如何正确做事（这也使专家更加紧张）。 专家将审查新手，从而快速改进代码。 专家会审查其他引起争执的专家（笑话）。

对于某些效果很好的软件，对于其他专家，他们只需填写"未发现问题"并签字。 这样就完成了正式程序，但是我对自己的一些"未发现问题"的发展进行了自我回顾，并与签署人就我所发现的问题（例如： FIELD-GROUPS。 不幸的是，大多数使用代码审查的公司都进行了类似的方框打勾练习。.

嗨，Suwandi Cahyadi 形式代码审查或代码演练具有许多好处。

请参阅Wikipedia作为进一步阅读的切入点 ：代码审查

当然，代码审查不会取代正式的语法检查 或任何测试程序，例如单元，积分或回归。 代码审查只是提高代码质量的另一个工具。 它遍及整个编程社区，我不明白为什么它不能在ABAP环境下工作。

实际上，很多年前，我为Bell Labs工作的ABAP新开发人员经历了代码审查的优点。 我的第一项任务之一是由同行评审代码，并相信或不阅读仅仅由我解释的代码，他们就发现了很多错误。 那甚至还没有开始任何其他测试。

我只是想知道为什么不经常使用代码审查。

最诚挚的问候

Dominik Tylczynski