Подтвердить что ты не робот

Что вам нужно от тестового жгута?

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

Мне нужна способность конкатенации и вложенных потоков TAP.

Ответ 7

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

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

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

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

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

Ответ 10

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

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

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