Question

我模拟了所有依赖项，并在下面的测试中进行了存根。是否仍将其视为单元测试或集成测试？我在网上阅读过一篇文章，您应该将两者分开，应该尽可能多地运行单元测试，并偶尔进行集成测试。我在单元测试方面经验不足，并且很难区分两者。

例如，我添加了新功能，并且以下测试失败，但是我已经测试了应用程序代码，并且可以按预期工作。我觉得我的测试太脆弱了，在更改源代码时，我目前需要不断更改测试或添加测试，这对我来说似乎不正确。

TEST_F(UserInterfaceTest, TransmitCalibrationWithWrongPacket)
    {
        std::vector<std::string> commandpathnames;

        for (int i = 0; i < 9; i++)
        {
            std::string txt("transmit_calibration");
            txt += std::to_string(i);
            txt += ".txt";

            commandpathnames.push_back(txt);
        }

        EXPECT_CALL(*m_View, DisableAndSwitchPanel());
        EXPECT_CALL(*m_View, CheckInstance(_, _));
        EXPECT_CALL(*m_View, GetSerialPortInstance()).WillRepeatedly(ReturnRef(serialport));
        EXPECT_CALL(*m_View, GetSerialPortAddress()).WillOnce(Return(port));
        EXPECT_CALL(*m_View, GetCalibration()).WillRepeatedly(Return(calib));

        EXPECT_CALL(*m_Param, SetFunction(_));
        EXPECT_CALL(*m_Param, GetFunction()).WillOnce(Return(TRANSMIT_CALIBRATION));
        EXPECT_CALL(*m_Param, GetTemperature());
        EXPECT_CALL(*m_Param, GetSurveyDelay()).WillOnce(Return(20));

        EXPECT_CALL(*calib, GetCommandPathNames()).WillRepeatedly(Return(commandpathnames));

        EXPECT_CALL(serialport, Read(_))
            .WillOnce(DoAll(SetArgReferee<0>(poll), Return(0)));

        EXPECT_CALL(serialport, Write(_))
            .WillOnce(DoAll(SetArgReferee<0>(identitycommand), Return(0)));

        EXPECT_CALL(*m_View, CustomEventDisplayData(_)).Times(AtLeast(1));

        EXPECT_EQ(wxTHREAD_NO_ERROR, m_Controller->TransmitMasCalibration());

        m_Controller->GetSemaphore()->Wait();
    }

Answer 1

转到wikipedia时，您会发现单元测试：

单元测试是一种软件测试方法，通过该方法可以测试源代码的各个单元，一个或多个计算机程序模块的集合以及相关的控制数据，使用过程和操作过程，以确定它们是否适合使用。

换句话说：您所做的任何种测试都可以称为单元测试。

事情是：该定义没有帮助。像art of unit testing这样的网站更具体：

在内存中运行（例如，没有数据库或文件访问权限）

导致：“ true”单元测试完全隔离地运行。您将 any 与其相关性切断了联系（除非这些依赖性在您的单元测试环境中执行“精细”）。

从这个角度来看：只要您的单元测试不需要完整的堆栈就可以正常运行，或者某些网络接口上可以访问到的东西……它们很可能是单元测试。

我宁愿区分单元测试和功能测试。他们俩都只做一小部分，而后者则具有一个或多个“确实”存在的依赖关系。

集成测试更进一步-在这里，您几乎没有“依赖关系”。

但真正的答案是：这些术语是 fuzzy 。不同的人有不同的看法。而且几乎不可能改变他们的看法。因此，真正的结论是：您（和您的团队）应该清楚地定义这些术语对您的含义，然后确保至少每个基于该代码工作的人都了解该构想。

关于“过于脆弱”方面：这里再次有两个视图。一方面，您专注于测试公共合同。理想情况下，您可以将一种实现完全替换为另一种实现，并且单元测试仍然有效。因为理想情况下，单元测试仅“给出该输入，期望该输出（行为）”。一旦开始测试实施细节，您的测试就会在实施发生变化时中断。这使测试的价值降低。

另一方面，测试特定的“内部”元素也可能很公平。那么，您需要对其进行测试。

但是如前所述： first 方法是关于测试公共合同的内容，而不是“如何”。

如何区分单元测试和集成测试？

1 个答案: