#c #unit-testing #automated-tests
#c #модульное тестирование #автоматизированные тесты
Вопрос:
В рамках моей лекции по C студентам придется решать задания. Каждое решение должно реализовывать одни и те же функции с одинаковой функциональностью и одинаковыми параметрами (имя функции, возвращаемое значение, параметры передачи). Отличается только код внутри.
Итак, я думаю о способе эффективного тестирования всех решений (около 30). Возможно, лучший способ — написать модульный тест, а также сценарий оболочки (или что-то подобное), который компилирует каждое решение один раз с модульным тестом и запускает его.
Но, возможно, есть другое и гораздо лучшее решение этой проблемы.
Ответ №1:
Причина, по которой модульные тесты являются одним из наиболее эффективных видов автоматизированного тестирования, заключается в том, что возврат инвестиций относительно невелик (по сравнению с другими типами тестирования), поэтому для меня имеет смысл написать набор тестов для проверки.
Вы могли бы даже зайти так далеко, что предоставить студентам набор тестов вместо спецификации, написанной в прозе. Это могло бы познакомить их с концепцией разработки, основанной на тестировании (хотя обычно мы склонны писать тесты итеративно, а не пакетами).
Комментарии:
1. Интересным моментом является предоставление студентам набора тестов. Возможно, я собираюсь это сделать, это могло бы сэкономить много работы (хотя я не против того, чтобы у моих студентов было много работы, но это должно быть эффективно).
Ответ №2:
да, модульные тесты являются очевидным решением для большинства случаев.
предупреждения компилятора и статический анализ также полезны.
выбор времени выполнения программы с учетом набора параметров является еще одним довольно автоматизированным вариантом — зависит от того, что вы заинтересованы в оценке.
другой вариант — создание базовых классов с хорошей диагностикой (реализацию которой вы можете заменить для своей оценки, если хотите). вы также можете предоставить интерфейсы, которые они должны использовать, и содержать две реализации. затем выполните программы как обычно, используя диагностическую реализацию. это зависит от того, что вы ищете.
Комментарии:
1. 1 отдельно для базового класса / интерфейса. Не все программы выражаются через классы (действительно, алгоритмы — это функции, а не классы).
2. в защиту классов / интерфейсов: это действительно зависит от того, что ищет OP. пример: если доступен хороший интерфейс многопоточности, и требуется, чтобы они его использовали, тогда тест может проанализировать, сколько потоков создано, максимальное количество активных потоков и так далее. если это тип коллекции или распределитель, то может быть сгенерирована статистика копирования и / или распределения. опять же, это зависит от того, что ищет macs и в каких деталях. некоторые вещи легче тестировать с этой точки зрения. поскольку им нужно только реализовать интерфейс… возможно, это неплохой вариант
3. Я никогда не говорил, что это плохой вариант сам по себе. Просто он не всегда подходит для текущей задачи.
4. @Matthieu M. ах, хорошо — я был сбит с толку, потому что я уже заявлял, что его использование ограничено.
Ответ №3:
Возможно, я упускаю что-то очевидное, но разве не было бы достаточно просто запустить код несколько раз со значениями параметров граничного тестирования?
Комментарии:
1. Дело в том, что у меня около 30 решений, и я думаю, что на компиляцию каждого из них вручную уходит слишком много времени. Или, может быть, я что-то упускаю?
2. @macs: Зачем вам компилировать вручную? Я предполагаю, что работа каждого студента отправляется по электронной почте или на веб-сайте. Просто скопируйте и вставьте его содержимое в тестовую среду, скомпилируйте и запустите.
3. Я хочу использовать решение «как есть», копирование и вставка, на мой взгляд, иногда подвержены ошибкам. Поэтому я хотел использовать скрипт, собрать все решения (из разных папок) и скомпилировать каждое из них в тестовой среде. Но я подумал, что может быть более разумное решение, вот почему я спрашивал.
4. @macs: вы можете установить требование, чтобы «make test» находился в каталоге, в который выполняется компиляция и запуск тестов, выполняемых в задании untarred… вам нет смысла знать, что нужно копаться, пытаясь разобраться в зависимостях.
5. @Tony: Я бы никогда не пытался откладывать работу в долгий ящик, не учитывая идеи студента в его / ее решении. Тестирование, если оно работает, должно быть только первым шагом, дающим мне небольшой обзор. Поскольку они используют premake4, должно быть легко добавить «make test» к каждому решению. Спасибо за это предложение.