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

[Интеррапт]

dup

[stenking]

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

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

Точно! Отличная иллюстрация почему тесты для веба малоэффективны - люди умнее и дешевле.

[Интеррапт]

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

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

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

[stenking]

dup

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

[stenking]

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

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

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

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

[Интеррапт]

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 - твоего поста еще не было, когда писал. Там объясняется, что совершенно очевидно, что если тест ловит баг возникший в результате редизайна, то он ловит этот баг если он не возник в результате редизайна. Там же объясняется, почему лишнее двоеточие может быть результатом именно редизайна
Иными словами, утверждение юнит-тесты никогда и предназначались для поиска ошибок, типа как "лишние двоеточие" выглядит оооочень неверным

[stenking]

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

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

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

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

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

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

Это всё очень даже логично. Но баги то другие. Т.е. я понимаю прекрасно для много людей, постоянно что-то ломается и т.д. Но в моём личном восприятии команда QA с ручным тестированием, повышеной адекватностью ( например в состоянии посмотреть на гит хаб что бы увидить какие файлы поменялись что бы знать куда усилия направлять ) работает намного эффективнее. Стоит ли ивестировать в автоматизацию которя может стоить + 20-50% проекта или в QA или и туда и туда - тут пусть каждый решает сам. Я писал тесты 10 лет а теперь считаю что это была ошибка и лучше бы злого qa взять.


Но всё это спефифично для 1) веб эппов 2) команд до 10 человек 3) стартапов до 10М пользователей.

[Интеррапт]

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

А были бы нормальные юнит тесты в проекте, то "адекватный отдел тестирования" сократился бы с 60 человек, до 30

Юнит тестинг - это де-факто стандарт для разработки проектов, ну кроме таких случаев как:

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

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

[crypto5]

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

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

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

Ок, скажем так, в юнит тесты для нахождения лишних двоеточий я не вижу большого смысла инвестировать усилия. В покрытии тестами сложной логики, да, вижу.

[Интеррапт]

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

У тебя прямо какие-то QA волшебные. Ну и каким образом QA-ю поможет факт того, что он увидел, что на github поменялся файл "GHSInvokation.m" ? Те QA, которые могут разобраться в твоем коде и сообразить, что именно этот код затрагивает - они обычно девелоперами работают, а не QA.

Стоит ли ивестировать в автоматизацию которя может стоить + 20-50% проекта или в QA или и туда и туда - тут пусть каждый решает сам. Я писал тесты 10 лет а теперь считаю что это была ошибка и лучше бы злого qa взять.

Да не стоит никогда это 20-50% проекта. Юнит тесты писать после определенной практики - как семечки лузгать. Пару минут займет, чтобы покрыть какой-то сложный метод. Че там писать его? Быстро проверил, что при таких-то условиях получаешь такие-то результаты или наоборот, при таких-то условиях получаешь такие ошибки. Обычно все-равно ведь проверяешь, как отработался тот или иной метод, ты же не пишешь какую-то функцию, которая чего-то вычисляет, не проверив, что она действительно работает? Ну так чего эту проверку не засунуть в отдельный метод? Не думал, что в 21-м веке люди будут утверждать, что юнит-тесты не нужны

[crypto5]

Это всё очень даже логично. Но баги то другие. Т.е. я понимаю прекрасно для много людей, постоянно что-то ломается и т.д. Но в моём личном восприятии команда QA с ручным тестированием, повышеной адекватностью ( например в состоянии посмотреть на гит хаб что бы увидить какие файлы поменялись что бы знать куда усилия направлять ) работает намного эффективнее. Стоит ли ивестировать в автоматизацию которя может стоить + 20-50% проекта или в QA или и туда и туда - тут пусть каждый решает сам. Я писал тесты 10 лет а теперь считаю что это была ошибка и лучше бы злого qa взять.


Но всё это спефифично для 1) веб эппов 2) команд до 10 человек 3) стартапов до 10М пользователей.

Да, для crud вебапов логика которых - перекладывание данных из mysql в html я бы тесты тоже не писал.
НУ и некоторых других аппликейшнов тоже, что не исключает что у автоматического тестирования хороших областей применения выше крыши.