使用junit做其他事情

junit！=单元测试

Junit是Java单元测试框架。通常，我们将其用于单元测试，但是很多时候我们也使用它来执行集成测试。主要区别在于，单元测试可测试单个单元，而集成测试则可测试不同类如何协同工作。这样，集成测试可以覆盖更长的执行链。这意味着它们可能比单元测试发现更多的错误，但同时它们通常运行更长的时间，并且如果测试失败，则更难定位错误。如果您（作为开发人员）意识到这些差异，那么使用junit执行非单元测试就没有错。

当使用junit框架执行系统测试时，我已经在生产代码中看到了示例，其中测试的执行链包括通过网络进行的外部服务调用。 Junit只是一种工具，因此，即使您知道其缺点，也没有本质上的问题。但是，在实际情况下，junit测试的执行是在正常的maven测试阶段执行的，并且一旦外部服务中断，代码就无法构建。这很不好，因为清楚地表明开发人员在创建代码时并未意识到包括外部服务和构建过程在内的全局情况。

说完这些之后，让我告诉您一个不同的故事，稍后再加入这两个主题。

我们说语言...很多

大多数时候，我们的程序都有用户界面。该界面包含文本，通常使用不同的语言。通常以目标代码为英文和当地语言。文本文字通常是外部化的，存储在“属性”文件中。对于多种语言，我们为每种语言都有单独的属性文件，每种属性文件都为id定义文字文本。

例如我们有文件

messages-de.properties
messages-fr.properties
messages-en.properties
messages-pl.properties
messages.properties

在Java代码中，我们通过Spring MessageSource调用来访问它们

String label = messageSource.getMessage("my.label.name",null,"label",locale);

我们，程序员有点懒

当我们没有一些文本翻译时，问题就来了。用不同语言指定标签实际文本的工作不属于程序员。程序员是精通Java，C和其他编程语言的人，但是当谈到自然语言时，他们并不那么光彩。我们大多数人不会说所有需要的语言。有人负责翻译文本。通常，不同的人使用不同的语言。其中一些工作速度更快，另一些工作速度较慢，编码只是迫不及待准备好翻译。在最终翻译可用之前，我们使用临时字符串。

所有临时解决方案都将成为最终解决方案。

临时字符串（只是英文版）进入了发行版。

流程和纪律：失败

为了避免这种情况，我们实施了一个流程。我们为每种翻译打开了一个Jira问题。翻译准备就绪后，它便会附在问题上。当将其编辑到属性文件中并提交到git时，问题已关闭。如此沉重的负担和开销使程序员为此放慢了速度，而纪律不明的程序员只是没有遵循该过程。通常这是一个坏主意。

我们得出的结论是，不转换为属性文件并不是真正的大问题。问题是不知道它丢失并创建发行版。因此，我们需要一个过程在发布之前检查属性文件的正确性。

光路过程与控制

手动检查会很麻烦。我们创建了junit测试，比较了不同的语言文件，并检查了另一个语言文件中是否没有键，并且这些值与默认的英语版本不相同。每次发布项目时都要执行junit测试。然后我们意识到其中一些值确实与英文版本相同，因此我们开始在语言文件的第一个位置使用字母“ X”来表示等待实际翻译值替换的标签。在这一点上，有人建议可以将junit测试替换为简单的“ grep”。几乎是事实，只是我们仍然希望发现丢失的键并在发布过程中自动测试运行。