Лучший способ для юнит-теста, занимающий слишком много времени - PullRequest
Новая
       9

Лучший способ для юнит-теста, занимающий слишком много времени

0 голосов
/ 04 июля 2018

У меня есть куча тестов, приближающихся к 100. Они больше не являются юнит-тестами, они больше похожи на интеграционные тесты. Мне было интересно, если есть лучше, чтобы проверить мой код. Я включил образец теста, который я выполняю. Мне нужно добавить ожидание в 1 секунду, потому что я использую потоки.

100 секунд каждый раз, когда я строю, кажется чрезмерным, и чем больше тестов я добавлю, тем хуже будет. 

TEST_F(UserInterfaceTest, DownloadConfiguration)
{
downloadconfigurationcommand = commands.DownloadConfiguration(20);
    downloadconfigurationresponse = Response::GetDownloadConfigurationResponse();

    EXPECT_CALL(*m_View, SetNoteBookSelection(Display::SurveyPanel));
    EXPECT_CALL(*m_View, SaveFilePathDialog()).WillOnce(Return(wxID_OK));

    std::string val("C:\\Temp\\version20.bin");
    EXPECT_CALL(*m_View, GetSavePath()).WillOnce(Return(val));

    EXPECT_CALL(*m_Param, SetFunction(DOWNLOAD_CONFIGURATION));
    EXPECT_CALL(*m_Param, SetPathName(_));
    EXPECT_CALL(*m_Param, SetSurveyTimes(_));
    EXPECT_CALL(*m_Param, SetSurveyDelay(_));

    EXPECT_CALL(*m_Param, GetFunction()).WillOnce(Return(DOWNLOAD_CONFIGURATION));
    EXPECT_CALL(*m_Param, GetPathName()).WillOnce(Return(val));
    EXPECT_CALL(*m_Param, GetSurveyTimes()).WillOnce(Return(1));
    EXPECT_CALL(*m_Param, GetSurveyDelay()).WillOnce(Return(20));

    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, CustomEventDisplayData(_)).Times(AtLeast(1));

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

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

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

    Sleep(1000);
}

Это то, что делает контроллер. 

wxThreadError wxframecontroller::DownloadConfiguration()
{
    wxThreadError err = wxTHREAD_MISC_ERROR;

    m_View->SetNoteBookSelection(Display::SurveyPanel);

    int dialog = m_View->SaveFilePathDialog();

    if (dialog == wxID_OK)
    {
        m_Param->SetFunction(DOWNLOAD_CONFIGURATION);
        m_Param->SetPathName(m_View->GetSavePath());
        m_Param->SetSurveyTimes(1);
        m_Param->SetSurveyDelay(sec_10);

        m_View->CheckInstance(m_View->GetSerialPortInstance(), m_View->GetSerialPortAddress());
        {
            CCThread* t = new CCThread(m_View, m_View->GetSerialPortInstance(), m_Param);
            err = t->Create();

            if (err != wxTHREAD_NO_ERROR)
            {
                wxMessageBox(_("Couldn't create thread!"));
                delete t;
                t = NULL;
            }
            else
            {
                err = t->Run();
            }

            if (err != wxTHREAD_NO_ERROR)
            {
                wxMessageBox(_("Couldn't run thread!"));
                delete t;
                t = NULL;
            }
        }
    }
    return err;
}

1 Ответ

0 голосов
/ 04 июля 2018

Каждый раз, когда вы добавляете сон в тест, вы фактически ожидаете, что произойдет что-то еще, но не синхронизируетесь с ним. Смотрите на любой сон в ваших тестах с большим подозрением.

Попробуйте написать свой код так, чтобы вы могли тестировать функциональность отдельно от потоков. Если вы не можете этого сделать, сделайте так, чтобы тест присоединился к потокам в конце (чтобы вы знали, что ваш тестовый разрыв фактически разрушил весь тест).

Обратите внимание, что ваш тест в настоящее время может случайно провалиться, если ваш компьютер будет загружен более высоко - это одно означает, что ваш тест нестабилен.

...