Является ли приемлемой практикой модульное тестирование программы на другом языке?

У меня есть статическая библиотека, которую я создал из С++, и хотел бы протестировать ее с помощью кода драйвера.

Я заметил, что одному из моих профессоров нравится делать свои тесты с помощью python, но он просто выполняет программу (а не библиотеку в этом случае, но исполняемый файл), используя случайные тестовые аргументы.

Я хотел бы воспользоваться этим подходом, но я понял, что это библиотека и не имеет основной функции; это означало бы, что я должен либо создать класс Driver.cpp, либо обернуть библиотеку в python, используя SWIG или boost python.

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

Является ли тестирование программ на другом языке принятой практикой в реальном мире или эта плохая практика?

Ответ 1

Я бы сказал, что лучше всего протестировать API, к которому будут подвергаться ваши пользователи. Другие тесты тоже хороши, но это самый важный аспект.

Если ваши пользователи собираются писать код C/С++, связанный с вашей библиотекой, тогда было бы неплохо иметь тесты, использующие вашу библиотеку таким же образом.

Если вы собираетесь отправить оболочку Python (почему бы и нет?), тогда вам нужно провести тесты Python.

Конечно, для этого есть и удобство. Может быть проще написать тесты на Python, и у вас могут быть ограничения по времени, которые сделают его более привлекательным и т.д.

Я предполагаю, что я говорю: нет ничего неправильного в том, что тесты на другом языке из тестируемого кода (что вполне нормально для тестирования REST API, например), но убедитесь, что у вас есть тесты для API с открытым доступом, как минимум.

Кроме того, по терминологии:

Я не думаю, что типы тестов, которые вы описываете, являются "модульными тестами" в обычном смысле этого слова. Вероятно, "функциональный тест" будет более точным.

A unit test обычно тестирует очень маленький компонент - например, вызов функции - это может быть один кусок большей функциональности. Модульные тесты, подобные этим, часто являются "белыми коробками", поэтому вы можете видеть внутреннюю работу вашего кода.

Тестирование чего-либо с точки зрения пользователя (например, тестов в командной строке вашего профессора) - это тесты "черного ящика", а в этих примерах - более функциональный, а не "единичный" уровень.

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

Ответ 2

Несколько вещей, которые нужно иметь в виду:

Если вы пишете тесты по коду, то, во что бы то ни стало, используйте любой язык, который лучше всего подходит для быстрой обратной связи. Это обеспечивает быстрый цикл тестового кода (и это тоже весело). НО.
Всегда есть хорошо написанные тесты на языке потребителя. Как ваш клиент/потребитель будет называть ваши функции? Какой язык они будут использовать? Использование одного языка минимизирует проблемы интеграции в жизненном цикле.

Ответ 3

Это действительно зависит от того, что вы пытаетесь протестировать. Практически всегда имеет смысл писать модульные тесты на том же языке, что и тестируемый вами код, чтобы вы могли сконструировать тестируемые объекты или вызвать те тесты, которые могут быть легко выполнены на одном языке, и проверить что они работают правильно. Существуют, однако, случаи, когда имеет смысл использовать другой язык, а именно:

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

Примером № 1 может быть программа, которая запускает несколько разных серверов, связанных друг с другом, выдает запросы на сервер и проверяет эти ответы. Или, в качестве более простого примера, программа, которая просто запускает тестируемое приложение как подпроцесс и проверяет, что он производит ожидаемые выходы для заданного ввода.

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

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

Ответ 4

Почему бы и нет, это потрясающая идея, потому что вы действительно понимаете, что вы тестируете устройство как черный ящик.

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

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

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

Ответ 5

Я бы сказал, это зависит от того, что вы на самом деле пытаетесь проверить. Для истинного модульного тестирования, я думаю, лучше всего протестировать на том же языке или, по крайней мере, двоично-совместимый язык (т.е. Тестирование Java с помощью Groovy - я использую Spock в этом случае, на основе Groovy, для модульного тестирования моего кода Java, так как я могу объединить Java с Groovy), но если вы тестируете результаты, тогда я думаю, что это справедливо для переключения языков.

Например, я проверил ожидаемые результаты при задании определенного набора данных при запуске приложения Perl через nose в Python. Это работает, потому что я не тестирую код Perl самостоятельно, но результаты этого кода Perl.

В этом случае для unit test фактических Perl функций, которые являются частью приложения, я бы использовал основанную на Perl тестовую структуру, такую как Test::More.