Что вам нужно от испытательного жгута?

Question

Я один из тех, кто входит в группу IETF Test Anything Protocol (TAP) (если вы заинтересованы, не стесняйтесь присоединиться к списку рассылки). Многие языки программирования начинают использовать TAP в качестве основного протокола тестирования, и они хотят от него большего, чем мы предлагаем в настоящее время. В результате мы хотели бы получить отзывы от людей, которые имеют опыт работы в xUnit, TestNG или любой другой структуре / методологии тестирования.

В целом, помимо простой проверки на соответствие или неудачи, какая информация вам нужна из тестового жгута? Просто чтобы дать вам несколько примеров:

• Имя файла и номер строки (если применимо)
• Время начала и окончания
• Диагностический вывод, такой как разница между тем, что вы получили, и тем, что вы ожидали.

И так далее ...

Answer 1

Определенно все вещи из вашего списка для каждого отдельного элемента:

• Имя файла
• Номер строки
• Пространство имен / имя класса / функции
• Тестовое покрытие
• Время начала и время окончания
• И / или общее время (для меня это было бы более полезным, чем два верхних элемента)
• Диагностический вывод, такой как Разница между тем, что вы получили и что ты ожидал.

От макушки головы не больше, но по группе тестов, которую я хотел бы знать

• название группы
• общее время выполнения

Answer 2

Произвольный набор тегов - поэтому я могу пометить тест как, например, «интеграция, пользовательский интерфейс, администратор».

(ты знал, что я собираюсь попросить об этом, не так ли: -)

Answer 3

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

Answer 4

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

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

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

Answer 5

К тому, что вы сказали, я бы добавил:

• Имя метода / функции / класса
• Инструмент подсчета покрытия, за исключением (не считайте эти методы)
• Результат N последних запусков доступен
• Мандат на то, что должны существовать способы легкого разбора результатов теста

Answer 6

Уникальный идентификатор (uuid, md5sum), позволяющий идентифицировать отдельный тест - скажем, для использования при вставке результатов теста в базу данных или идентификации их в трекере ошибок, чтобы дать возможность QA повторно запустить отдельный тестовое задание.

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

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

Answer 7

Мне бы хотелось иметь возможность объединять и вкладывать потоки TAP.

Answer 8

Идея расширения для TAP:

1..4
ok 1 - yay
not ok 2 - boo
ok 3 - yay #json:{...}
ok 4 - see my json

Возможность прикрепить комментарий #json ... - может быть безопасно проигнорировано существующим кодом - четко определенные теги могут быть легко зарезервированы на testanything.org - легко создавать, анализировать и читать сложные типы - Ямл это боль

Answer 9

• дополнительный вывод цвета ascii, зеленый для хорошего, желтый для ожидающего, красный для ошибок

• идея ожидающих вещей

• сводка в конце отчета о тесте команд, которые будут запускать отдельные тесты, где

• Элемент списка

  • что-то пошло не так

  • что-то в тесте ожидало

Answer 10

Я использую TAP в качестве протокола вывода для набора простых методов тестирования C ++ и обнаружил следующие недостатки:

• шаги теста нельзя разделить на группы (есть только группировка по нескольким сценариям тестирования; но для запуска всех тестов в нашем программном обеспечении мне нужен как минимум еще один уровень группировки, чтобы один шаг теста был идентифицирован как «Соединение с БД» -> «Проверка переподключения» -> «Шаг проверки № 3»)
• полезно видеть разницу между ожидаемым и фактическим результатом; Я либо печатаю diff в stderr (как комментарий), либо запускаю графический инструмент diff
• протокол и инструменты должны быть действительно независимыми от языка. Например, до сих пор я знаю только инструмент Perl для «проверки» для запуска тестов, который ограничен использованием скриптов Perl

В конце выходные данные теста должны подходить в качестве основы для простой генерации файла отчета в формате HTML, в котором очень кратко перечислены успешные тесты, дан подробный вывод для неудачных тестов и возможен быстрый переход в среду IDE к неудачному тесту линия.