Pull to refresh

Comments 6

Я сейчас плавно учу Rust, и там тестирование даётся в главе №11, а основы ввода-вывода — в главе №12. И это офигенный подход. Написал трейт? Напиши тест.


Главная боль всякого php — в том, что начинающий начинает писать раньше, чем понимает что пишет.

К слову о тестировании, вопрос в зал. Есть ли у кого опыт тестирования экселевских файлов? Кто, как и чем это делает? Кроме данных в ячейках нужно тестировать формулы, стили и визуальное представление.


Кейс совершенно обычный — сервис, генерирующий отчёты, счета, акты и т.п.

Мне кажется, тут смешали две группы людей: будущие профессионалы-программисты и условные «домохозяйки», которые хотят себе себе сайт-визитку или малинку с чайником связать. Вот для первых тезис «пытаться изучать тестирование плюс что-либо ещё — ошибка» я бы развил в «следовательно они должны начинать с тестирования». Тестирование очень сильно способствует элегантности кода, а правило «тесты — код первого порядка и подчиняются тем же требованиям, что и основной код» способствует элегантности тестов.
Есть ещё известный эффект, что мотивация сильно падает, если долгое время не видно результата — если стек глубокий, а до hello world'а ещё пилить и пилить. Так вот, если параллельно делать тесты, то эффект сильно слабеет, во всяком случае для меня лично.

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


Что до DI, глобальных переменных, time.Now и моков — это всё очень простые вещи. Им сложно учить пока это абстракции, и начинающий не понимает про что и зачем ему вообще рассказывают. Как только у него в простых тестах начинают вылезать проблемы из-за отсутствия всего вышеупомянутого — объяснить что это, зачем оно нужно, и как это применять — становится очень просто. В общем, здесь нет реальной проблемы, достаточно рассказывать про это во-время.


А вот в откладывании тестов "на потом" — проблема есть. Если не приучать к тестам с пелёнок, то потом они так и будут писать… :)

А вот в откладывании тестов «на потом» — проблема есть. Если не приучать к тестам с пелёнок, то потом они так и будут писать… :)

Нахожусь сейчас как раз в такой ловушке — «так и пишу». Но у нас на фирме вообще нет культуры разработки, так что начиная свой путь тут я не слышал от «старших товарищей» про тесты, работу в команде, даже локальный git у нас «добровольно-принудительный».
Но время идет, проекты растут, и я уже пришел к пониманию того, что без тестов хуже и хуже, дольше и дольше. Теперь только нужно перебороть себя и, отодвинув на время текущие задачи, начать плотно разбираться с тестированием.
Нужно разделять тесты на те которые для 100% покрытия и надежности всего приложения, и те которые чтобы избежать рутинной самостоятельной проверки работоспособности кода. Второю категорию нужно писать сразу, так как это сама суть программирования не делать руками одно и тоже более 2 раз.
Sign up to leave a comment.

Articles