我知道单元测试是什么，为什么应该使用它以及如何编写它们。然而，我不确定我是否正确地理解了术语"自动化测试"answers"持续集成"。我对这些有一些大致的了解，但想知道它们在实践中看起来如何，例如在PHP中(或至少在其他语言中)。所以:
-
术语"自动化测试"与"单元测试"相同吗?或者"自动化测试"应该被认为是单元测试类的集合?
-
"持续集成"只是在开发团队中组织工作的问题，其目标是在每天结束时拥有最新的和经过测试的软件修订。因此，每个人都应该经常将自己的代码放入代码库(例如在每个工作日结束时)，并且每个人都应该将他们的单元测试提交给运行所有单元测试(执行自动化测试)的测试管理器。因此，在自动化测试(执行所有单元测试)和热修复bug之后，我们有了一个可发布的软件代码修订版本。
单元测试!=自动化测试
单元测试是相当古老的。它验证代码的(微小)单元(方法、类)是否按预期工作。例如，验证边界条件、逻辑路径等。因此，单元测试也可以是手工的。例如，你输入一些输入并手动验证它是否有效。
自动化测试是不需要人工执行测试或解释结果的测试。因此，这些测试可以在命令下运行，并将告诉您是否一切正常。自动化测试可以是自动化的单元测试，也可以是系统级/验收测试或性能测试或其他任何东西…
你很接近…只不过不是在一天结束的时候，而是几乎每时每刻。持续集成构建的主要目的是快速反馈(好处:随时都有可能发布软件的修订版)和更少的时间集成每个人的更改。每当有人签入时，CI机制将检出所有的源代码，构建以检查编译错误，然后很可能启动单元测试，最后是一些系统级测试。这样，可以尽早检测到错误的签入/失败(并且在某些情况下，您可以配置它，使签入永远不会进入版本控制，即恢复)。
自动化测试与单元测试:我的理解是单元测试是自动化测试的一个子类。顾名思义，自动化测试是不需要人工干预就可以运行的测试:机器应该能够运行它们。单元测试是它们的一个子集:它们验证单个功能单元。我看到的最好的定义是Kent Beck:"如果一个测试失败了，有多少地方可能是错的?"答案越接近1，测试就越"单元化"。其他自动化测试可能是集成测试，它会告诉你应用程序的行为并不完全像预期的那样，但不一定会告诉你应用程序的哪一部分有缺陷。
持续集成是关于限制"集成地狱"，又名"但它在我的机器上工作!"持续集成不是希望多个开发人员总是确保他们的更改与整个团队的工作保持同步，并且他们没有破坏应用程序，而是努力拥有一个"防御性"存储库机制，也就是说，每次有人提交时，存储库都确保没有任何破坏。至少，这涉及到确保最新的提交仍在构建，最多，它还通过运行自动化测试来强制现有功能仍然存在。
我自己还在适应这些术语，但我对CI和自动化测试的理解是，当您推送代码时，测试正在运行。
我们使用Jenkins与HipChat集成，所以每次有人推到GitHub, Jenkins运行测试，让我们知道，有时大声，如果构建已经被打破。