В этой заметке я поделюсь опытом автоматизации тестирования специфичных сквозных (E2E) сценариев, с которыми мне пришлось столкнуться.
Для успешного решения этой задачи, я нарушил один из важных принципов тестирования - делай тесты независимыми. Далее я покажу, почему я так поступил, и что из этого вышло. Быть может, этот опыт будет полезен моим коллегам.
Я считаю эту статью вредной, и постараюсь показать – чем именно. Кто-то из читателей согласен с утверждениями Мартина. Возможно, кто-то из них не смотрел с позиции QA на эти утверждения. Именно для них я изложил свою точку зрения.
Компания, в которой я сейчас работаю, занимается разработкой программного обеспечения, краеугольным камнем которого являются различные алгоритмы: расчёта значений, построения графов связей, проверки состояний и т.п. В связи с этим, нам очень важно уделять особое внимание unit-тестированию.
Один из моих коллег-автоматизаторов упомянул, что к нему обращаются разработчики с вопросом: "А как написать unit-тест?". Не конкретный тест, а "в принципе". Это послужило для меня поводом подготовить эту статью, и адресована она молодым программистам. Они смогут ознакомиться с рекомендациями, которым стоит следовать при разработке unit-тестов. Но также может быть любопытна и QA-инженерам - ведь полезно получить представление об аспектах тестирования, выполняемого разработчиками.