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, приходите к нам на курс!