Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Как правильно организовать структуру тестирования добавления, удаления, объектов в таблицу


(Viktor Kazankov) #1

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

Вопрос, как организовать структура проверок для тестирования этого функционала?

Первый вариант:

  1. Добавить измерение в таблицу
  2. Добавить числовые данные в измерение
  3. Добавить картинку в измерение
  4. Сохранить
    А теперь идут проверки:
  5. Проверить что измерение сохранилось
  6. Проверить что числ. данные сохранились
  7. Проверить что картинка сохранилась
  8. Удалить измерение

Т.е. получаем один большой тест проверки добавления измерения в таблицу

Второй вариант:
Тест А

  1. Добавляем измерение в таблицу
  2. Проверяем что измерение добавлено
  3. Удаляем измерение из таблицы
    Тест В
  4. Добавляем измерение в таблицу
  5. Добавляем числовые данные в измерение
  6. Проверяем что данные добавились
  7. Удаляем измерение
    Тест С
  8. Добавляем измерение в таблицу
  9. Добавляем картинку в измерение
  10. Проверяем что картинка добавлена
  11. Удаляем измерение

Т.е. имеем несколько маленьких тестов

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


(Александра Литвиненко) #2

С точки зрения автотестов - верный второй(правило- тесты должны быть независимые).


(Дмитрий Мирошник) #3

2-й правильный. Почему - написала @karueglazki. Более того, я бы изменил “Удаляем измерение” на “возвращаем таблицу к первоначальному состоянию”. Поможет избавиться от мусора в случае фейла теста, когда измерение может внестись не полностью (особенно если это не 1 строчка в таблице, а группа связанных записей в нескольких таблицах) и метод по удалению записей столкнётся с проблемами удаления несуществующих или повреждённых данных.


(rmerkushin) #4

Очистку данных лучше переносить в setup, так можно быть точно уверенным что тест не упадет при старте если setup завершился успешно, так же это спасет от фейлов после teardown’а от других тестов. Грубо говоря какая-то такая структура должна быть:

Test Suite Setup:

  • подключение к БД, удаленному серверу по SSH и т.п.

Test Case Setup:

  • очистка\удаление тестовых данных, например: delete from table или truncate table
  • заливка\создание тестовых данных

Test Cases:

  • test 1
  • test 2
  • test N

Test Suite Teardown:

  • отключение от БД, SSH и т.п.