среда, 5 октября 2022 г.

1 автотест = 1 проверка (на примере Postman-a)

Вообще это правило и ручных тестов касается, но сегодня поговорим на примере автоматизации в Postman. Итак, общее правило тестов, особенно автоматических:

1 тест = 1 проверка

Почему именно так? Да потому что проще будет понять "почему всё упало".


Давайте посмотрим на примере Users. Дергаем метод http://users.bugred.ru/tasks/rest/getuser:

{

  "email": "test_cu_11@mail.com"

* Email может меняться, так как система живая, данные создаются и удаляются.

Итак, мы хотим проверить ответ и пишем такой автотест:

var jsonData = pm.response.json();

pm.test("Все поля заполнены верно"function () {
    pm.expect(jsonData.name).to.eql("Красавчик");
    pm.expect(jsonData.avatar).to.eql("http://users.bugred.ru/");
    pm.expect(jsonData.email).to.eql("test_cu_11@mail.com");
    pm.expect(jsonData.birthday).to.eql("01.01.1900");
    pm.expect(jsonData.gender).to.eql("m");
    pm.expect(jsonData.date_start).to.eql("11.11.2000");
    pm.expect(jsonData.name1).to.eql("Тестовый, ясен пень");
    pm.expect(jsonData.surname1).to.eql("Иванов");
    pm.expect(jsonData.fathername1).to.eql("Петров");
    pm.expect(jsonData.cat).to.eql("Маруся");
    pm.expect(jsonData.dog).to.eql("Ушастый");
    pm.expect(jsonData.parrot).to.eql("Васька");
    pm.expect(jsonData.cavy).to.eql("Кто ты?");
    pm.expect(jsonData.hamster).to.eql("Хомяк");
    pm.expect(jsonData.squirrel).to.eql("Белая горячка к нам пришла");
    pm.expect(jsonData.phone).to.eql("333 33 33");
    pm.expect(jsonData.adres).to.eql("адрес 1");
    pm.expect(jsonData.inn).to.eql("123456789012");
});

Когда всё работает, то и проблемы не видно. Зеленый же!


Но что будет, если какое-то поле пришло не то? Давайте пока специально сломаем дату рождения:

pm.expect(jsonData.birthday).to.eql("Ой, что-то не то!");

Тест упал:


Но можно ли понять из ошибки, что именно не так? Ведь это мы сейчас специально сломали и знаем, где проблема, а в реальной жизни будет наоборот: тест упал и нам надо разобраться, баг в коде программы или автотеста. Итак, читаем сообщение:

Все поля заполнены верно | AssertionError: expected '01.01.1900' to deeply equal 'Ой, что-то не то!'

 

Название теста есть — я понимаю, какой автотест сломался. Но какая из проверок внутри? Ведь у меня 18 проверок внутри 1 теста!!

Я не знаю, какая из них плохая, ведь постман не написал мне, на каком именно поле он сломался. И мне надо поискать по своему тесту 'Ой, что-то не то!', чтобы понять, про какую вообще строку речь. Не очень удобно. 

А что будет, если сломались разные поля? Давайте к сломанной дате рождения добавим плохое имя кошечки:


pm.expect(jsonData.birthday).to.eql("Ой, что-то не то!");

pm.expect(jsonData.cat).to.eql("Маруся упадет");


Запускаем тест, получаем ошибку:

Упс, а сообщение то не изменилось! Оно спокнулось на первой проваленной проверке, а дальше даже не выполняло. То есть если у нас упадет первая из 18 проверок, результат остальных мы не узнаем до исправления этой. 

А что, если баг в коде и разработчик заболел и исправят это минимум через неделю? Мы теряем результаты 17 других проверок! Или начинаем изгаляться, комментировать код и писать "раскомментировать после фикса такой-то задачи", потом раскомментировать в итоге забудут и будет наша дата рождения вообще не покрыта тестами. Очень нехорошо!

А зачем нам терять результаты проверок? Что именно мы пытаемся сэкономить? Здесь тогда надо или писать код теста на чистом языке программирования с циклами и прочим, который будет доводить дело до конца, даже если одна проверка упала + выводить четкое сообщение "где именно сломалось".

Или можно просто расписать каждую проверку в отдельном тесте (я часть проверок опущу):


var jsonData = pm.response.json();

pm.test("Имя заполнено верно"function () {
    pm.expect(jsonData.name).to.eql("Красавчик");
});

pm.test("Аватар заполнен верно"function () {
    pm.expect(jsonData.avatar).to.eql("http://users.bugred.ru/");
});

pm.test("Email заполнен верно"function () {
    pm.expect(jsonData.email).to.eql("test_cu_11@mail.com");
});

pm.test("ДР заполнена верно"function () {
    pm.expect(jsonData.birthday).to.eql("Ой, что-то не то!");
});

pm.test("Пол заполнен верно"function () {
    pm.expect(jsonData.gender).to.eql("m");
});

pm.test("Имя кота заполнено верно"function () {
    pm.expect(jsonData.cat).to.eql("Маруся упадет");
});

Запускаем тесты, получаем результат:

4 проверки прошли успешно, 2 нет. И мы сразу четко видим, в каких полях есть проблемы, а в каких — нет.

Так проще тестировщику с локализацией. Так проще разработчику — исправить разом все проблемы, а не получать их по одной. 

Так проще менеджеру — он не вникает глубоко в ваши тесты, а смотрит общий результат в системе CI. И ему надо комплексно понять, у нас 1 проблема или 10. И когда у нас тесты написаны в стиле "10 в 1", то картина получается недостоверная.

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


Итого

Когда тесты написаны "внутри одного теста 10 проверок", это плохо:

  • тест сложно "читать" при ревью
  • тест сложно поддерживать, куча всего внутри
  • если тест упал на 2 проверке, то 8 проверок мы просто потеряли
  • сложно локализовать при падении
Поэтому лучше придерживаться правила "1 тест = 1 проверка".


PS — а если хотите научиться писать тесты посложнее, чем expect.to.eql в Postman-e, приходите к нам на курс!

Комментариев нет:

Отправить комментарий