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

[Boriskin]

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

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

Юнит тесты - просто инструмент, где то отлично подходят, где то - вообще нах не сдались. Предвосхищая вопрос - "где не сдались?" - да любая multi-threaded asynchronous ситуация с ожиданием чего либо (ответ из сети, освобождение shared ресурса etc), другими словами - ситуация, когда отсутствие заранее определенного состояния аппы в конретный момент времени - нормально.

[Интеррапт]

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

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

Юнит тесты - просто инструмент, где то отлично подходят, где то - вообще нах не сдались. Предвосхищая вопрос - "где не сдались?" - да любая multi-threaded asynchronous ситуация с ожиданием чего либо (ответ из сети, освобождение shared ресурса etc), другими словами - ситуация, когда отсутствие заранее определенного состояния аппы в конретный момент времени - нормально.

У нас, похоже, разное понимание, что такое unit test. То, про что вы говорите, например "ответ из сети" - это можно делать при помощи integration test (т.е. этот этап происходит после unit testings и перед validation testing). А для unit test никакого ответа из сети ждать не нужно, т.к. вместо этого будут просто mock обьекты использоваться. У unit test своя область применения.

[Boriskin]

А для unit test никакого ответа из сети ждать не нужно, т.к. вместо этого будут просто mock обьекты использоваться.

Тогда какой смысл в использовании юнит тестов для ситуации с описанным выше раскладом? Проверить логику девелопера, что все вызывается в правильном порядке и с правильными аргументами?

[Интеррапт]

А для unit test никакого ответа из сети ждать не нужно, т.к. вместо этого будут просто mock обьекты использоваться.

Тогда какой смысл в использовании юнит тестов для ситуации с описанным выше раскладом? Проверить логику девелопера, что все вызывается в правильном порядке и с правильными аргументами?

С описанным выше - это с каким? С сетью? Ну например, чтобы посмотреть, что ничего не поменялось в обработке протокола. Сложно ответить на ваш вопрос, потому что "результаты из сети" - понятие очень рассплывчатое. Результат от сервера может mock-аться на клиенте и на основе его проверяться, что в обработке клиентом результата ничего не изменилось и не поломалось. Теоретически то же самое можно делать и через интегрейшн тесты, но они как правило выполняются достаточно долго, а юнит тесты - намного быстрее, что для разработчика - большой плюс. К тому же если ты кодишь клиент и напортачили серверные разработчики, то всегда можно им тыкнуть в лицо, что мол с моим юнит тестом все продолжает работать, а с интегрейшен тестом - валится... мол не поменяли ли вы часом чего-то на сервере?
Опять же, для многих ситуаций должны использоваться интегрейшн тесты, но боюсь, что меня вообще заклюют, а то народ здесь к любым, написанным программистами автоматизационным тестам - враждебно относится
И главное, что никто же не утверждает, что unit test - это серебряная пуля, которая полностью решает вопросы с багами. Но то, что это удобный инструмент для того, чтобы отсеивать определенное кол-во багов, а также защищать от разнообразных поломок в коде - для меня как бы вообще очевидно. А веру в то, что хороший QA сам найдет все баги - этого я вообще не понимаю. Да и просто самому неприятно дураком выглядеть, когда на тебя открывают тривиальные баги, которые должны были еще быть отсеяны на этапе юнит тестирования.

[АццкоМото]

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

Не знаю, что тебя заставляет так думать, но в действительности все не так, как на самом деле
а именно после введения юнит-тестов отдел тестирования увеличился с 30 до 60 человек, т.е. все ровно наоборот. разумеется, юнит-тестами отдел тестирования не занимался. более того, поскольку это был не богопротивный аджайл, а православный CMM Level 4, у меня была вся статистика, а предсказание по количеству багов на проекте я делал еще до того, как кто-то начал кодировать и - чудо какое - угадывал достаточно точно. так вот влияние юнит-тестирования - нулевое. абсолютно. проверено статистикой и чуть ли не тысячей человеко-лет труда. объясняется это очень просто: кодер кодит примерно с одинаковой скоростью. на написание кода с юнит-тестами за фиксированное время нужно больше кодеров, потому что объем кода (основного + тесты) больше. один из главных источников багов - взаимодействие между разными людьми. иллюстрирую: если 10 человек могут написать какую-то систему за год, то 20 таких же точно человек за полгода едва ли уложатся, а если уложатся, то багов будет МИНИМУМ в 2 раза больше

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

Это потому что лично ты принял это за аксиому. А я - не принял.

(а) Программист просто ленится писать юнит-тесты, т.к. это скучно

Как ты понимаешь, в команде, сертифицированной на CMM Level 4 лень программистов не интересует никого. Если сказано сверлить квадратные дырки, то все будут сверлить квадратные или работать в другом месте

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

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

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

Еще раз: твои юнит-тесты не дают никакого волшебного ответа почему все сломалось. Они просто говорят "ой, сломалось" - точно так же, как это делают автоматизированные блэкбокс тесты. а дальше - одно существенное различие. если кодер что-то сделал неправильное, что ему кажется правильным, он тупо правит юнит-тест. если сломался тест нормальный, он заявляет тестерам свою любимую мантру works as designed, на что в ответ получает сырым тапком по морде - требования прочитай, козлина тупая, и не приставай к царю
чуешь разницу? эти практики тоже не на пустом месте сложились.

[АццкоМото]

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

Ок. Почти согласен. Если добавить к "сложной логике" еще логики с четким соответствием входных данных и выходных, без влияния извне тестируемого юнита - то я только двумя руками "за". Мы тут выкидываем всяческие общения по сети с другими устройствами - потому что модуль не может знать, что ему прилетит - кучу всяких user interactions, нетривиальных выборок из внешних хранилищ данных (тривиальные можно оставить) и так далее

[АццкоМото]

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

А вот в правильных командах собирается статистика, изменения в каких местах потенциально ломают какую функциональность. Причем не только на уровне файлов, но и на уровне функций в них. Тулзом, автоматизированно. И если выходит новая метка, в которой 50 коммитов, ТУЛЗА аггрегирует эти данные и рекомендует, что тестировать. А тестеры еще и смотрят в описание коммитов - подробные, а не разгильдяйские и примерно прикидывают, что ЕЩЕ могло сломаться если корявые ручки кодеров меняли такую-то функциональность.
По сравнению с тупенькими юнит-тестами, это rocket science

[АццкоМото]

С сетью? Ну например, чтобы посмотреть, что ничего не поменялось в обработке протокола.

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

Сложно ответить на ваш вопрос, потому что "результаты из сети" - понятие очень рассплывчатое. Результат от сервера может mock-аться на клиенте и на основе его проверяться, что в обработке клиентом результата ничего не изменилось и не поломалось.

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

[Boriskin]

А для unit test никакого ответа из сети ждать не нужно, т.к. вместо этого будут просто mock обьекты использоваться.

Тогда какой смысл в использовании юнит тестов для ситуации с описанным выше раскладом? Проверить логику девелопера, что все вызывается в правильном порядке и с правильными аргументами?

С описанным выше - это с каким? С сетью? Ну например, чтобы посмотреть, что ничего не поменялось в обработке протокола. Сложно ответить на ваш вопрос, потому что "результаты из сети" - понятие очень рассплывчатое. Результат от сервера может mock-аться на клиенте и на основе его проверяться, что в обработке клиентом результата ничего не изменилось и не поломалось. Теоретически то же самое можно делать и через интегрейшн тесты, но они как правило выполняются достаточно долго, а юнит тесты - намного быстрее, что для разработчика - большой плюс. К тому же если ты кодишь клиент и напортачили серверные разработчики, то всегда можно им тыкнуть в лицо, что мол с моим юнит тестом все продолжает работать, а с интегрейшен тестом - валится... мол не поменяли ли вы часом чего-то на сервере?

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

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

Может проще работать чуть качественне, чтобы просто не делать тривиальных ошибок?

[stenking]

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

А вот в правильных командах собирается статистика, изменения в каких местах потенциально ломают какую функциональность. Причем не только на уровне файлов, но и на уровне функций в них. Тулзом, автоматизированно. И если выходит новая метка, в которой 50 коммитов, ТУЛЗА аггрегирует эти данные и рекомендует, что тестировать. А тестеры еще и смотрят в описание коммитов - подробные, а не разгильдяйские и примерно прикидывают, что ЕЩЕ могло сломаться если корявые ручки кодеров меняли такую-то функциональность.
По сравнению с тупенькими юнит-тестами, это rocket science

Я по такому же принципу стараюсь всё придерживается только по простому конечно. Т.е. продакшин пуши стараюсь делать практически каждый день.
QA смотрит что поменялось с коммита ХХХХХХХХХХХХХХ по сегодня и старается понять где это всё используется. Если видит что поменялась функция "сожрать яблоко" то делает поиск по коду что бы посмотреть где она используется. Если логика в файле то тестирует эту функциональность. Если css то смотрит как оно с изменениями. Т.е. всё ноу хау оказалось в том что бы писать нормальные имена и комментами обяснять что это делает и показать QA как пользоватся гит хабом и как там комментировать

[crypto5]

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

Ок. Почти согласен. Если добавить к "сложной логике" еще логики с четким соответствием входных данных и выходных, без влияния извне тестируемого юнита - то я только двумя руками "за". Мы тут выкидываем всяческие общения по сети с другими устройствами - потому что модуль не может знать, что ему прилетит - кучу всяких user interactions, нетривиальных выборок из внешних хранилищ данных (тривиальные можно оставить) и так далее

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

[dotcom]

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

Я бы не горячился по поводу "легко".

[crypto5]

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

Я бы не горячился по поводу "легко".

Приведите пример когда тяжело?

[dotcom]

Приведите пример когда тяжело?

Я работал на системой Video Quality Monitoring'а. Свит для тестов у нас по сложности был примерно равен production инфраструктуре. Качество надо было мониторить на клиенте и на сервере одновременно. Свой собственный UI, логгер, бэкенд с тестовыми хуками, трафик шейпер, свой собственный VPN с симуляцией разных сетевых конфигураций, мегабайты тестовых пакетов, видео файлов разных форматов, клиентов под все платформы... Все только для тестов. Это не unit, а system/integration testing, но mocking UI и сети там был совсем непростой и, я бы сказал, мучительный.
В разработке мобильного UI тоже не все так просто. Простые формочки без навороченной навигации смокировать не так сложно. Динамические интерфейсы с анимацией, OGL компонентами... - good luck.

[stenking]

dub