Программист. с чего начать?

[Интеррапт]

dup

А юнит тест прям мне емаил пошлёт и скажет что ему контент не понравился?:)

Нет, конечно. Но разве об этом речь? unit testing и собственно blackbox тестирование продукта - как бы понятия совершенно разные.

[Интеррапт]

Точно! Нужно написать тест который проверяет или нет дубликатов. А потом прочитать получше и увидеть что Патрол <> Полис и подумать а нафига я сейчас убил 2 часа

Ну ладно, ладно. Не заметил, а гадость сказать хотелось

[stenking]

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

Смотря где. Вот тебе классическая задача веб эппа. Форма ввода описания, выбор категорий с подгрузкой, умный алгоритм подбора кийвордов. Что тут можно сделать?

Всю логику можно заюнитестить, включая твою "категории с подзагрузкой" и "умный алгоритм кийвордов". Потому как он сегодня умный, а завтра кто-то где-то чего-то подкрутил и он уже стал не таким умным.

Угу можно. Создать тестовую дату, потратить 2 дня описывая всё это. А можно просто взять реальную базу данных и посмотреть или то что выскакивает имеет смысл или нет

[Интеррапт]

Угу можно. Создать тестовую дату, потратить 2 дня описывая всё это. А можно просто взять реальную базу данных и посмотреть или то что выскакивает имеет смысл или нет

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

[stenking]

Угу можно. Создать тестовую дату, потратить 2 дня описывая всё это. А можно просто взять реальную базу данных и посмотреть или то что выскакивает имеет смысл или нет

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

5 программистов ( 20 человек компания ) , 2 года в работе, второй раунд инвестиций на 20М в процессе - тесты не пишем и пока не очень хочется. Притом я можно сказать вырос на TDD.

[Интеррапт]

5 программистов ( 20 человек компания ) , 2 года в работе, второй раунд инвестиций на 20М в процессе - тесты не пишем и пока не очень хочется.

Ну и не пишите, делов это. Намного проще не писать, чем писать

[stenking]

5 программистов ( 20 человек компания ) , 2 года в работе, второй раунд инвестиций на 20М в процессе - тесты не пишем и пока не очень хочется.

Ну и не пишите, делов это. Намного проще не писать, чем писать

Ну так в этом же и цель Зачем сложно то когда можно просто) Притом я не против тестов особенно как АццкоМото правильно сказал они реально помогают ( ну там оттестировать array_merge например ). Или когда эпп такой матёрый где стабильность много важнее любых фичей. Но для активно развивающегося стартапа тесты могут быть зло. Они сожрут огромноое количество времени, усложнят код и что самое противное так это то что реальные баги ещё не поймают.

А реальные баги в моём примере это

1. Опечатка

2. Так как кийворды берутся у пользователей то некоторые подсказки были неанглийские

3. Один хитрый юзер ввёл слово фак 1000 раз в обход JS валидации то алгоритм подсказывает его на верхнем месте

и т.д. И не один из этих реальных багов тестами не поймаешь.

[АццкоМото]

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

[crypto5]

Что тут можно сделать?

Убрать лишнее двоеточие, например

Мухаха. И "Private Patrol Officer" два раза повторяется. Вот тебе, стенкинг, твои филипинские тестеры

Точно! Нужно написать тест который проверяет или нет дубликатов. А потом прочитать получше и увидеть что Патрол <> Полис и подумать а нафига я сейчас убил 2 часа

Юнит тесты слабо эфективны для нахождения хитрых багов, они больше что бы задекларировать ожидаемое поведение вашей системы, и сигнализировать если кто-то что-то поломает когда будет добавлять фичу или рефакторить. Когда у вас будет значительно больше 5-и программистов, большая часть колектива сменится по пару раз, будет куча старого кода, а полное регрессивное тестирование на каждый чих будет занимать 4 недели и стоить много денег, покрытие тестами очень здорово окупиться как в плане продуктивности разработки так и в плане стабильности продукта.

Нy и в нормальном процессе вам не надо писать 2 часа тест. Инфраструктура тестирования должна развиваться вместе с кодом, и вам достаточно вбить в тесте что-то initDb().addKeyword('hello').addKeyword('ehlo') что бы заинициализировалась база с кучей около продакшн данных + ваши данные необходимые для теста.

[Интеррапт]

Самое смешное, что юнит-тесты практически наверняка не нашли бы лишнее доветочие. Или там грамматическую ошибку. Ибо автор теста и кода один человек, вооруженный мощнейшим копи-пейстом

Ребята, о чем вы говорите? юнит-тесты никогда и предназначались для поиска ошибок, типа как "лишние двоеточие". Юнит тесты так же никоим образом не могут заменить тестеров/QA, это всего-лишь еще один из инструментов, чтобы понизить кол-во ошибок в коде и понизить вероятность того, что кто-то чего-то сломал в коде, а никто и не заметил.

[АццкоМото]

Самое смешное, что юнит-тесты практически наверняка не нашли бы лишнее доветочие. Или там грамматическую ошибку. Ибо автор теста и кода один человек, вооруженный мощнейшим копи-пейстом

Ребята, о чем вы говорите? юнит-тесты никогда и предназначались для поиска ошибок, типа как "лишние двоеточие". Юнит тесты так же никоим образом не могут заменить тестеров/QA, это всего-лишь еще один из инструментов, чтобы понизить кол-во ошибок в коде и понизить вероятность того, что кто-то чего-то сломал в коде, а никто и не заметил.

Объясни для убогих и тупых, как тест может понизить количество ошибок, при этом не находя багов

[crypto5]

Самое смешное, что юнит-тесты практически наверняка не нашли бы лишнее доветочие. Или там грамматическую ошибку. Ибо автор теста и кода один человек, вооруженный мощнейшим копи-пейстом

Ребята, о чем вы говорите? юнит-тесты никогда и предназначались для поиска ошибок, типа как "лишние двоеточие". Юнит тесты так же никоим образом не могут заменить тестеров/QA, это всего-лишь еще один из инструментов, чтобы понизить кол-во ошибок в коде и понизить вероятность того, что кто-то чего-то сломал в коде, а никто и не заметил.

Объясни для убогих и тупых, как тест может понизить количество ошибок, при этом не находя багов

Тест находит баги, он не находит баги "типа как лишнее двоеточие"

[Интеррапт]

Объясни для убогих и тупых, как тест может понизить количество ошибок, при этом не находя багов

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

[АццкоМото]

Тест находит баги, он не находит баги "типа как лишнее двоеточие"

Интересно. Например, у нас раньше была жестко сверстанная форма. Все поля из строковых ресурсов, разумеется, с двоеточиями - ибо нужны они там. А потом мы заредизайнили форму, чтобы поля различные конструировались динамически исходя из каки-то соображений, а двоеточия расставлялись автоматом, ибо тот же ресурс используется отныне в сообщении об ошибке "Вы не ввели данные обязательное поле Мое Фамилиё". И из всех строковых ресурсов двоеточие убрали, а про один - забыли. Это в точности что должен находить юнит-тест: поломанная старая хункциональность в результате редизайна. Капитан Очевидность подсказывает, что если у нас юнит-тесты достаточно хороши, то они найдут такой баг даже если еще никакого редизайна не было, а просто у кого-то тряслись ручки после веселой ночи порока и разврата. А если они недостаточно хороши, то они не выполняют и свою основную задачу

ЗЫ. я несколько лет жизни потратил на создание нормального адекватного отдела тестирования, с нуля и до человек эдак 60. вот уж эти все простые плюсы-минусы очевидных подходов разобраны по деталькам больше 10 лет назад. когда я все это читаю, так и хочется сказать "ха! туристы"

[АццкоМото]

Объясни для убогих и тупых, как тест может понизить количество ошибок, при этом не находя багов

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

Т.е. все-таки смысл тестов - искать баги. Любых тестов, в том числе и юнит-тестов.
Выше ответ crypto5 - твоего поста еще не было, когда писал. Там объясняется, что совершенно очевидно, что если тест ловит баг возникший в результате редизайна, то он ловит этот баг если он не возник в результате редизайна. Там же объясняется, почему лишнее двоеточие может быть результатом именно редизайна
Иными словами, утверждение юнит-тесты никогда и предназначались для поиска ошибок, типа как "лишние двоеточие" выглядит оооочень неверным