тестовые классы

Question

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

Пролистав некоторое время здесь, я нашел один комментарий, в котором предлагалось использовать такую ​​технику, сделав класс тестирования другом настоящего класса.

В ретроспективе оба эти метода должны были быть для меня очевидны.

То, что я ищу, - это методы специально для классов альфа-тестирования / юнит-тестирования, без увеличения веса тестируемого класса.

Какие техники вы лично использовали и рекомендуете?

Answer 1

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

edit: См. Также: Этот вопрос SO . Обратите внимание, что это можно сделать (верхний ответ), но также обратите внимание, что ответ на втором месте (с небольшим отрывом) говорит более или менее то же, что я упоминал выше.

Answer 2

Звучит так, будто вам не нужно юнит-тестирование, которое является корректной проверкой работоспособности интерфейса класса. Вам не нужно вообще менять свой класс, чтобы проводить юнит-тестирование. Если вы ищете способ проверить внутреннее состояние вашего объекта, чтобы он оставался непротиворечивым, вам следует изучить методы Design by Contract , которые могут проверять внутреннее состояние изнутри объекта.

Answer 3

eJames прав. Модульное тестирование должно фокусироваться на интерфейсе, чтобы входы в класс производили правильный вывод. Любая приватная или дружественная переменная являются частью реализации и не тестируются специально.

Если вы допустили ошибку в закрытой подпрограмме для класса, это вывело бы неверный вывод.

Answer 4

Я много занимался сборкой фреймворка - в основном вызывал классы / интерфейсы, которые хотел протестировать. На занятиях не было никакой дополнительной работы.

Я также несколько раз создавал классы, которые делали публичные методы виртуальными. Я получил от них и сделал тестовые классы / объекты. Методы тестового объекта вызывали методы родительского (реального класса), а также регистрировали все вызовы и результаты. Это было больше для ведения журнала, чем для тестирования, но оно также работало.

Методы, описанные выше, я делал до того, как появилась шумиха по поводу модульного тестирования и тому подобное. (около конца 1990-х годов)

Тогда это работало хорошо для меня, но я не слишком много сделал с вещами Junit / nunit, и я действительно хочу дать им толчок в реальных проектах.

образец для одного метода

Класс Вещи

{...

общественность: виртуальный DoStuff (); , .. };

класс ThingTest: общедоступная вещь

{

виртуальный DoStuff ()

{

// записать вызов и параметры.

// сделать звонок родителю

// записать возвращаемое значение

// возвращаем возвращаемое значение

}

* +1034 *};

Answer 5

Это хорошо. Обычно я также хотел, чтобы тестовый класс был не только отдельно от оригинала, но также и в совершенно другой DLL / EXE, а также тестировал «настоящий» скомпилированный класс из «настоящей» DLL / EXE, в которую он был скомпилирован .

Одна дополнительная техника, которую я нашел, состоит в том, чтобы переопределить класс в инструменте тестирования. Точно скопируйте определение класса, но сделайте все публичным. Это позволяет инструменту тестирования иметь «белый ящик» доступа к классу, но фактическая реализация все еще из реального кода класса.

т.е.

class myClass
{
private:
    int foo;
public:
    myClass() { foo = 0; }
}

и затем:

class test_myClass
{
public:
    int foo;
public:
    test_myClass();
};

void test()
{
    myClass *c = new myClass();
    test_myClass *t = (test_myClass*)c;
    // All methods are called on c.
    // White-box access is available through t.
};

Ох ... и DevStudio 2008 теперь имеет некоторые действительно классные возможности модульного тестирования, включая возможность объявить «друг» сборку , которая обеспечивает доступ белого ящика ко всем внутренним классам сборки проходит испытания.