问当你是团队中的新人时，你能对现有集成和单元测试的质量做些什么呢？

EN

首先，正如其他海报已经写过的那样，您应该高兴地理解单元/集成测试(不是以技术的方式，我的意思是应该理解它的原因)，并由管理层推动。

在你开始做任何事情之前，你应该把问题暴露给管理层，为什么要做一些事情，并且非常外交，这样他们就不会认为你是世界上最好的程序员(即使你是！:-)。也许他们会告诉你，应用程序将被全新的东西所取代，如果是的话，为什么要麻烦呢？也许他们会意识到，在每个版本发布之前，这将是很好的，并且加快测试阶段。和你的队友保持外交关系，也许有无数的理由可以解释它是什么样子，只是没有理由去寻找一个罪魁祸首。

一个更好的办法是试着和他们交谈，这样他们就可以参与其中，这样你就会有更少的机会作为一个聪明的混蛋出现，它会比“我”更“我们”。

现在，把重点放在你想做的事情上。优先处理任务，总是知道你的首要任务将永远是你当前的项目任务。至于您的测试问题，下面是我要做的，分三个阶段：

1. 如何在单元测试和集成测试之间进行区别？以下解决方案可能适用，并不是独占的：
   • 重构测试用例方法的名称(而不是类，因为正确的行为是让测试用例与测试类共享相同的名称)
   • 创建两个注释，一个名为"UnitTest"，另一个名为"IntegrationTest“。这些注释可以用于类和方法。如果整个类由单元测试或集成测试组成，则可以使用正确的注释标记该类。如果没有，您可以用正确的注释标记每个方法。此外，这些注释在启动测试(第3阶段)之前，对于动态注入固定装置也是有用的。

2. 对于每个集成测试，请列出预期在每个测试开始时在数据库中的"dataset“是什么，以及在测试结束时应该删除的数据集(例如:表X，需要将"id”设置为"1"，"name“设置为"foo”等)。请注意，您删除的内容可能比开始时更大/更小，因为代码本身可能分别从持久性层添加/删除对象。您可能很快就会注意到，这些测试用例中有几个需要相同的数据集或同一数据集的一部分。
3. 前两个阶段可以很快完成.和其他人相比。现在您已经拥有了数据集，您可以为每个需要它的测试用例使用create夹具。但那要花些时间..。所以你可以做一个，看看花了多少时间，并估计你需要多少时间去做每件事。此外，你也可以用这个测试向同事们展示你做了什么，以及为什么当你不需要有一个特定状态的数据库来执行测试时，生活会变得如此简单。

您可能会注意到，阶段1、2和3可以在单个测试类上完成，如果您想快速地向同事/管理人员展示如何进行测试的话。这也是有用的，正如Péter T r k所写的那样，以便立即向你的队友展示“好方法”，让他们停止产生错误的代码。不过，我认为第二阶段的其余部分，即识别整个测试数据集，最好在一大步内完成。

至于所有这些背后的API/技术，您似乎知道这个主题。

希望能帮上点忙。

注意:对于我的建议，我假设您使用Java/C#编写代码，在这里我知道注释和AOP是可能的。我相信这在其他语言中也是可能的，但我不会写一些我不知道的东西。

你不能把所有的测试都修复在一起。我认为你应该专注于改进这个词，而不是大修。无论是管理层，不是开发人员，都不会同意彻底改革，但如果你证明有一种方法可以在不影响项目的情况下改善项目，那么他们就更有可能倾听。

首先，除非您有高质量的测试覆盖率，否则不能“修复”或重构现有代码，所以我将首先关注修复您的测试基础结构。

列一张清单，列出需要改进的东西，并试着把它们放在优先顺序。我认为独立和单独运行测试的能力(因此它们不会相互影响)以及单元测试和集成测试的分离是首先要做的事情。你需要让你和其他人做正确的事情变得容易。

就应用程序代码而言..。您将无法对应用程序架构进行彻底的大修，这样就可以更好地对其进行单元测试。相反，当您输入新代码时，尝试应用使单元测试更容易的原则(比如依赖注入)。您可能会认为这还不够大，但是如果开发人员看到了这些好处，他们会很快发现这一点，这是令人惊讶的。只是需要一个人开始做出更好的改变。

和你的团队谈谈，让他们收买。你能做的最重要的事情之一是遵循“童子军规则”，做一些小小的改进，让一个班级或考试比你发现的更好。如果整个团队都采用这条规则，事情就会变得更好。

过了一段时间，您将有许多遵循良好原则的代码，以及应用程序中形状不好的区域。在这一点上，您已经知道了什么是好的，并且团队可以决定对旧的遗留的东西做一个更大的重构是有益的，还是它可以继续生存下去。

我必须承认，我会把它看作是一种罕见的礼物，在那里他们已经有了大量的单元/集成测试--到目前为止，我从未有过这样的运气。即使不是所有的人都像他们应该的那样工作，他们已经付出了很大的努力，即使团队和管理人员并不总是遵循最佳实践，他们仍然致力于这个目标，所以你不需要花时间争论为什么单元测试值得写。

然而，您所描述的测试确实需要一些改进。但是当你和队友讨论问题时，你需要注意你的语气。如果您一开始就说“关于测试本身的一切都是完全错误的”，那么您可能很快就会疏远团队的其他成员。相反，你应该专注于如何改善目前的状况，我必须重复一遍，根据我迄今为止的经验，现在的状况仍然远远好于平均水平。

海事组织，你的第一个目标应该是阻止团队产生更多的坏测试。因此，首先要向你的队友展示每一个具体改进的好处。如果他们看到某种技术的有用性--无论是削减外部依赖关系，在每个测试之后恢复原始状态，还是分离单元和集成测试--他们将开始应用它们。从长远来看，这本身将缓慢但肯定地改善测试基础的总体质量(如果现在有1000个坏测试用例，并且团队到明年会产生1000个好测试，那么坏测试的比率就会从100%降到50%)。一旦得到了保护，您就可以根据具体情况决定重构现有的测试。再一次，小小的改进会随着时间的推移而产生巨大的变化。

顺便提一句，从你职位的语气来看，我觉得你可能也处在一个我以前也在的地方:不信任别人做的工作，不能把任务委托给任何人，因为担心他们的工作达不到你自己的质量标准。根据我的经验，这不是一个好地方，因为从长远来看，它很容易导致个人冲突和倦怠。你不能独自做每件事，你必须和团队的其他成员一起工作。你们只能一起成功。