2014-09-23 3 views
0

Это первая часть вопроса пары, который у меня есть, разделенный в разных потоках.Как правильно проверить классы

Прежде всего, пока я создаю класс, который будет использоваться в какой-либо другой программе, где я должен разместить свой тестовый код. Если мой класс будет использоваться каким-либо другим файлом, должен ли я тестировать свой класс с отдельным файлом или в одном файле?

Например: Я создаю класс Token, он объявлен в Token.h и реализован в Token.cpp, но пока я тестирую, чтобы убедиться, что все работает, можно использовать метод main() в моем Token.cpp или это вызовет проблемы, когда я захочу использовать токен позже? Если нет в Token.cpp, я предполагаю, что я проверил бы с отдельным файлом типа Token_Test.cpp? или я полагаю, что могу проверить в токене с помощью main(), а затем прокомментировать, как только я уверен, что он работает по своему желанию?

Благодаря

+0

ИМХО Ваш вопрос скорее слишком широк. – 101010

+0

Интересно, я не понимаю, как я могу быть более конкретным, но я постараюсь быть. Я спрашиваю о том, как люди должны пытаться проверить свой код при определении классов. Очевидно, если Token никогда не будет использоваться ничем другим, я мог бы протестировать в Token.cpp с помощью main().Но если я собираюсь использовать токены в других файлах, у этого также будет main(), будет ли main() в Token.cpp вызвать проблему или нет? – user2386276

+0

Вот материал Microsoft Visual studio 2013 по модульному тестированию с C++ http://msdn.microsoft.com/en-us/library/hh598953.aspx, поскольку модульное тестирование - это то, что кажется вам так, как вы хотите. Вам нужно будет потратить некоторое время на чтение на модульном тестировании на C++. Если вы хотите поместить функцию 'main()' в какой-то класс, вам действительно следует использовать директивы препроцессора для #ifdef, а не комментировать это. См. Также http://stackoverflow.com/questions/87794/c-unit-testing-framework и http://stackoverflow.com/questions/242926/comparison-of-c-unit-test-frameworks –

ответ

1

свой код как отдельные, как можно дальше от ваших тестов. В идеале тесты не должны мешать вашему коду вообще, но это не всегда возможно.

+0

Я так много думал, но не был полностью уверен, была ли «лучшая практика», – user2386276

0

Это может быть хорошим кандидатом для Unit Test, который почти всегда является полностью отдельным исполняемым файлом. У меня были очень хорошие результаты, работая с каркасом CPPUnit.

Поскольку ваше программное обеспечение становится более сложным (т. Е. Больше классов и т. Д.), Модульное тестирование может помочь вам сохранить в нем очень стабильное и простое в обслуживании состояние. Они, конечно же, не являются серебряной пулей, которая устраняет все известные проблемы, но они помогут обеспечить, чтобы каждый класс работал так, как должен.

0

Вы определенно хотите, чтобы ваш тестовый код был отделен от вашего тестируемого кода. Вы действительно не хотите, чтобы ваш тестовый код имел какие-либо зависимости от вашего тестового кода.

В проекте любого размера вы, вероятно, захотите написать свои тесты, используя unit testing framework в отдельной сборке/библиотеке, но для чего-то достаточно малого вы можете попробовать запустить все свои тесты, передав параметр командной строки вашей основной функции. Вот абсурдно простой пример:

Greeting.h:

#pragma once 
#include <string> 

std::string getGreeting(); 

Greeting.cpp:

#include "Greeting.h" 

std::string getGreeting() { 
    return "Hello world!"; 
} 

test.h:

#pragma once 
void test(); 

test.cpp:

#include "Test.h" 
#include "Greeting.h" 

#include <cassert> 
#include <iostream> 

void test() { 
    auto greeting = getGreeting(); 
    assert(greeting == "Hello world!"); 
    std::cout << "Test passes!\n"; 
} 

main.cpp:

#include "Test.h" 
#include "Greeting.h" 

#include <iostream> 

void run() { 
    std::cout << getGreeting() << "\n"; 
} 

int main(int argc, char *argv[]) { 
    if (argc > 1 && strcmp(argv[1], "-t") == 0) 
    test(); 
    else 
    run(); 
} 

Live demo

Смежные вопросы