От джуна до сеньора: Как стать востребованным разработчиком

Тесты

Тесты – это большая (и не всегда однозначная) часть любого крупного проекта. Тестирование предполагает проверку функций, корректности их работы, проверку ожидаемых результатов, и не всегда оно заключается только в тестировании кодом. Тестирование выполняется вручную или автоматически, этим могут заниматься коллеги-тестировщики, и (в самом худшем случае) у вас всегда будут тестировщики со стороны – пользователи вашего продукта.

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

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

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

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

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

Тестирование человеком всегда дает вашему проекту преимущество, потому что человек – это невероятная аналитическая машина, способная совершать фантастические глупости. Как разработчику вам никогда даже в голову не придут вещи, которые пользователь может сотворить с продуктом. Буквально. Просто поверьте мне на слово. Тестировщики, конечно, будут относиться к вашему проекту более бережно, однако, как опытные специалисты, они (как и вы в коде) интуитивно чувствуют слабые места и выявляют проблемы продукта куда быстрее и качественнее самих разработчиков. «Володя, я кликнул на это поле ввода три раза, отсоединил и подсоединил обратно клавиатуру, подпрыгнул на стуле, и наше приложение зависло» – да, готовьтесь именно к такому.

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

Как правило, приступая к очередной задаче, вы, как разработчик, располагаете всеми данными, необходимыми для ее реализации (если нет – вы явно пропустили фазу анализа и сбора требований, ай-яй-яй). Следовательно, вы можете заранее описать сценарии работы еще не написанного кода. На этом принципе базируется методология разработки и тестирования TDD. Формализм и аккуратность будут вашими лучшими помощниками при написании таких тестов, однако знайте, что есть грань, пересекать которую считается дурным тоном. Однажды формализм заставит вас написать проверку того, что true является true. Встаньте, передохните и постарайтесь больше не превращаться в робота.

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

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

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

Тезисы

■ Тесты нужны, даже если вас убеждают в обратном.

■ Идеальный вариант, если ваш код будут проверять тестировщики или хотя бы ваши коллеги.

■ Терпите скуку формальных тестов, это окупается.

■ Один упавший тест – минус сотня недовольных клиентов.

Задание

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

История из жизни

Вам никогда не встречался тест, который использует текущее системное время для проверки работоспособности проекта? Мне встречался. А знаете, чем будет знаменит такой тест, чем он запомнится вам, когда вы с ним встретитесь? А вы обязательно с таким встретитесь или даже напишете свой. Ваши тесты будут либо выполняться безукоризненно гладко, либо останавливаться с ошибками, и вы потратите уйму времени на то, чтобы понять: все, что меняется между их запусками, – это секунды, которые сменяют друг друга. Тик, тик, тик… Успешный тест, неуспешный тест, успешный тест…