Я не люблю писать тесты для чужого кода, когда код написан плохо, использует очень много зависимостей и когда он не объектно-ориентированный. Это скучно, грустно и не интересно.
Много говорят о тестах, но до сих пор почему-то больше говорят, чем делают. А ведь если сразу же писать свой код и тесты, то код получается лучше, красивее и менее бажный.
Есть разные мнения по поводу того, когда нужно писать тесты. Очень часто слышу, кто тесты нужно писать еще до того, как вы начали писать реальный код. В реальности я больше встречаю случаи, когда тесты пишут в самом конце или не пишут вовсе, потому что не хватает времени.
Заранее получается написать только в тех случаях, когда картина уже четко ясна, какой код нужно будет писать, что не всегда возможно.
Я же предпочитаю писать тесты во время. Я пишу класс, и если добавляется метод, который выполняет какую-то логику, то тут же создаю тест для тестирования даже простых вещей. Я как бы тестами тестирую свой же код. Когда тесты выполняются верно, тогда уже запускаю сайт и руками тестирую результат, чтобы убедиться, что все действительно работает.
По мере дальнейшей разработки я постоянно запускаю все тесты. В VS есть возможность создать плейлист для тестов и таким образом группировать их. Для каждой функции лучше иметь свой собственный плейлист, который можно открыть в любой момент в окне дерева тестов и запускать их одним кликом по мере надобности.
Если тесты поддерживать постоянно в рабочем состоянии, то они реально помогают. Меня уже много раз спасали тесты, когда видишь NullException баг и думаешь, что его так просто исправить, просто добавив значение по умолчанию. А потом запускаешь тесты, а оказывается, что где-то есть логика, завязанная на Null значение и эта логика сломана.
Тесты реально помогают тестировать, и если вы будете подходить к этому вопросу так же, то вы полюбите, как удобно с помощью кода тестировать свой код. Ведь вы же тестируете свой код руками? В случае с сайтами вы вынуждены запускать его, выполнять какие-то действия и так далее. А некоторые баги ведь требуют только определенного сценария, например, срабатывают только на новом пользователе. Чтобы воспроизвести баг нужно руками создать пользователя, потом выполнить действия, которые приводят к багу. Когда ошибку удалось воспроизвести, ее начинаешь дебагить и снова нужно повторять шаги с регистрацией, воспроизведением ошибки. А если с первого раза не удалось определить причину бага, то шаги опять приходится повторять. А когда баг починили нужно еще раз повторять руками процесс регистрации пользователя и нужно убедиться, что баг исправлен.
Если работать правильно, а не хуях, хуяк - в продакшн, то тестировать баги это такое утомительное занятие, которое вызывает больше раздражения. Наверно поэтому и происходят регулярные хуяки в продакшн, потому что лень руками тестировать.
А если написать код, который будет все тестировать за вас, это же будет одно удовольствие. Пришел баг, создал тест, который воспроизводит ошибку, исправил ошибку, запустил тест, чтобы убедиться, что все в порядке и отдал тестерам, которые руками подтвердили решение проблемы. Желательно, чтобы программист тоже руками проверял, но это уже не так смертельно.
В общем, на вопрос - когда писать тесты, я бы ответил - во время того, как вы пишите код, когда вы исправляете баги. Если вам прислали баг, то при его исправлении обязательно напишите тест для этой ситуации, чтобы убедиться, что баг не всплывет снова. Сколько уже было случаев, когда старые баги снова появлялись в программах, потому что одну и ту же ошибку повторяют разные программисты.
Не откладывайте тесты на потом. Если что-то отложить на завтра, то это не будет сделано никогда.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
согласен, тоже так делаю
Есть мнение, что не так важно когда писать тесты, до (TDD) или после, лишь бы тесты были написаны. Поэтому хорошо, когда в компании внедрена практика написания тестов на любой более-менее нетривиальный кусок логики. На прошлом месте работы задачи просто не проходили код-ревью, пока в них не было тестов.
Тут важно понимать, что TDD это методология разработки, а не тестирования. Покрытие кода тестами при TDD это скорее приятный бонус. Советую всем почитать книгу Kent Beck "Test Driven Development".
Одну и ту же задачу можно решить Х способами и когда я начинаю, очень часто вижу, что надо решить, но не всегда видно с первого захода решение. Очень часто приходится экспериментировать. Это если писать страничку Обратная Связь для сайта, конечно же понятно как все будет работать заранее.
Я описал то, как я это делаю. Если ты хочешь делать по другому, Билл Гейтс тебе судья. Я же не говорю, что это неверно, это правильно, но я так не делаю. Да, тесты проверяют поведение, которое требует бизнес и если его написать до, во время или после это все еще все тот же самый тест. Ты же не напишешь тест, который будет проверять умножение 4 и 2 с результатом 9 в конце разработки или во время. Так что если тебе удобнее писать заранее, делай так, как удобнее.
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
