24.02.2017, 01:23
Долбоёбский комикс.
Многие старые программы и игры до сих пор работают как часы - без ошибок и зависаний.
Сейчас обмазываются юнит-тестами - а на выходе забагованная хуйня.
Не нужно "повышать качество приложения" как пишет автор комикса, потому что говно-код уже не исправить, хоть сколько не подпирай его костылями.
Многие старые программы и игры до сих пор работают как часы - без ошибок и зависаний.
Сейчас обмазываются юнит-тестами - а на выходе забагованная хуйня.
Не нужно "повышать качество приложения" как пишет автор комикса, потому что говно-код уже не исправить, хоть сколько не подпирай его костылями.
У нас была тема, что до создания метода класса, создать юнит-тесты под него. Мол, так шустрее и быстрее получается.
И всё таки не уверен, сильно ты не любишь юнит-тесты или нет, но в крупных проектах - они маст-хэв - мелкие модули можно тестировать без запуска всей программы. Да что там, даже если ещё половина проекта в стадии "В голове того кодера".
И всё таки не уверен, сильно ты не любишь юнит-тесты или нет, но в крупных проектах - они маст-хэв - мелкие модули можно тестировать без запуска всей программы. Да что там, даже если ещё половина проекта в стадии "В голове того кодера".
Это уже относится к криворукости, а не к тестированию. Тесты надо делать в соответствии с тем, что требуется от метода и здравым смыслом, на окружение там немного класть, порядок - тоже не важен, ты проверяешь как метод будет реагировать на разные входные данные, которые сам же и задаёшь в тесте (В том числе и получаешь от другого метода, но чаще рекомендуют делать тесты атомарными).
А в чем проблема сделать программу-болванку и тестить методы в ней? Делов даже на С на пару минут.
я сколько ни пытался освоить эту чудесную методологию, чот никак не могу. либо код достаточно примитивен, что нафиг его тестировать - трата времени; либо настолько сложен, что хз как его тестировать. атомарно не получится. Алсо поддержка тестов начинает влиять на саму архитектуру в сторону ее усложнения. когда вместо простого и понятного синглтона, появляются кучи фабрик, кучи хабов, которые эти инстансы позволяют находить, связность растет.
статьи тоже обычно не помогают, сколько их читал, все рассматривают тестирование хелловорлда, а потом всё, конец. как тестировать ебический распределенный кластер - думай сам.
у коллег, которые пишут тесты, тоже чота ничего почерпнуть не получается. как увижу, что на тестирование класса с 3мя полями внутри (rgb цвет) тратится 2 страницы кода - так впадаю в уныние :(
статьи тоже обычно не помогают, сколько их читал, все рассматривают тестирование хелловорлда, а потом всё, конец. как тестировать ебический распределенный кластер - думай сам.
у коллег, которые пишут тесты, тоже чота ничего почерпнуть не получается. как увижу, что на тестирование класса с 3мя полями внутри (rgb цвет) тратится 2 страницы кода - так впадаю в уныние :(
Тут да, если код слишком примитивен, и юнит-тесты ни к чему. Но когда громадный проект, пилят его не один человек, проект рассчитан на последующее расширение, управляет командой ещё третий человек, да и куча всего прочего... Юнит-тесты - это гарантия того, что объекты будут работать так, как это требуется.
А вот уже при багах, можно смотреть требования, и выяснять, чего да как произошло.
Вообще, рекомендую кинуть взор на компанию СКБ Контур и их обучающие материалы. Очень хорошо излагают суть и основные принципы разработки ПО и его тестирования. Есть стажировки и обучающие материалы.
А вот уже при багах, можно смотреть требования, и выяснять, чего да как произошло.
Вообще, рекомендую кинуть взор на компанию СКБ Контур и их обучающие материалы. Очень хорошо излагают суть и основные принципы разработки ПО и его тестирования. Есть стажировки и обучающие материалы.
>Юнит-тесты - это гарантия того, что объекты будут работать так, как это требуется
Увы, только если юнит-тест правильно написан. Да, это ещё один уровень контроля, в какой-то мере это тебя дисциплинирует, и в целом имхо хорошо, но это не гарантирует качества кода, точно так же как код без тестов не обязательно забагован.
Увы, только если юнит-тест правильно написан. Да, это ещё один уровень контроля, в какой-то мере это тебя дисциплинирует, и в целом имхо хорошо, но это не гарантирует качества кода, точно так же как код без тестов не обязательно забагован.
Вот в том-то и дело, что юнит-тесты ловят только механические ошибки в коде, но не логические. Грубо говоря, когда ты пишешь и метод(объект) и тест, ты ДУМАЕШЬ, что он должен работать именно так, и напишешь и то, и другое именно так. И оно прекрасно отработает.
Приведу гипертрофированный пример. Пишешь метод, принимающий инт, отдающий булеан. По всей логике выходит, что если твой инт менее 101, то возвращаем тру, если более - то фэлз. А в проде все падает один раз на 10000, но зато очень громко, и вообще в другом модуле и с совершенно непонятной ошибкой. Потому что ты забыл учесть фазу луны, варианты валентности хлора и долбоеизм Трампа, потому при значении -14762 метод должен возвращать фэлз.
При этом твой простейший класс создается ебанной фабрикой из конфига размером с войну и мир, весь код покрыт тестами и все типа збс, кроме размера проекта, из-за которого этот ебанный баг искали два месяца, а не два дня.
Понимаешь, механические ошибки кода обычно не сильно страшны, и их ловят QA на раз два. А вот логические пиздец как важны. Но из-за относительно небольшого проекта, какаим бы он был без тестов и других тараканов, проект становится неебическим монстром со 100500 уровней абстракций, и в нем реальную работу выполняет отсилы 20% кода, остальное занимается обслуживанием всей этой хуеты.
Я как-то переписывал такой пиздец с жабы со всей этой поебенью на простецкий код на скалке. Бляяяяяя. 150 классов в один? Да легко! Никаких блядских фабрик, никаких ограничений типа "мы так не делаем потому что Архитектура/написано в умной книжке". Был Очень Большой Проект, стал аккуратненький маленький. Без изменения функционала.
Понимаешь, ловить ошибки в проде - охуеть как важно. И тут тесты не просто допизды, они своим существованием конкретно усложняют дело.
Приведу гипертрофированный пример. Пишешь метод, принимающий инт, отдающий булеан. По всей логике выходит, что если твой инт менее 101, то возвращаем тру, если более - то фэлз. А в проде все падает один раз на 10000, но зато очень громко, и вообще в другом модуле и с совершенно непонятной ошибкой. Потому что ты забыл учесть фазу луны, варианты валентности хлора и долбоеизм Трампа, потому при значении -14762 метод должен возвращать фэлз.
При этом твой простейший класс создается ебанной фабрикой из конфига размером с войну и мир, весь код покрыт тестами и все типа збс, кроме размера проекта, из-за которого этот ебанный баг искали два месяца, а не два дня.
Понимаешь, механические ошибки кода обычно не сильно страшны, и их ловят QA на раз два. А вот логические пиздец как важны. Но из-за относительно небольшого проекта, какаим бы он был без тестов и других тараканов, проект становится неебическим монстром со 100500 уровней абстракций, и в нем реальную работу выполняет отсилы 20% кода, остальное занимается обслуживанием всей этой хуеты.
Я как-то переписывал такой пиздец с жабы со всей этой поебенью на простецкий код на скалке. Бляяяяяя. 150 классов в один? Да легко! Никаких блядских фабрик, никаких ограничений типа "мы так не делаем потому что Архитектура/написано в умной книжке". Был Очень Большой Проект, стал аккуратненький маленький. Без изменения функционала.
Понимаешь, ловить ошибки в проде - охуеть как важно. И тут тесты не просто допизды, они своим существованием конкретно усложняют дело.
Хз, вот как раз маразм вида "тест на каждый метод" - это и есть пиздец. 5 строк метода и 10 теста на него. Рефакторинга все боятся даже не как огня, а как лесного пожара. Если кто-то заикнется про "нужно сразу писать идеальную архитектуру", даже на таком микроуровне - прошу закрыть за собой дверь шкафа со стороны Нарнии и не высовываться, потому что заказчики всегда очень даже из реального мира.
Тесты отдельных модулей как черных ящиков по вполне определенным спекам взаимодействия между модулями - ок. Эти спеки меняются не часто, и можно переписать. Не проходит модуль - баг летит тем, кто за него в ответе, а там у себя разберутся.
Можно и отдельные функционально-важные части тестами покрывать. Но не до маразма.
Тесты отдельных модулей как черных ящиков по вполне определенным спекам взаимодействия между модулями - ок. Эти спеки меняются не часто, и можно переписать. Не проходит модуль - баг летит тем, кто за него в ответе, а там у себя разберутся.
Можно и отдельные функционально-важные части тестами покрывать. Но не до маразма.
А что мешает тестить методы в программе пустышке, копирующей только нужные интерфейсы от основной? А там больше изоляции, меньше идиотизма. В свое время была кретиническая мода на уменьшение числа методов и классов в приложении, ну так это нифига не улучшало ситуацию, а код становился запутанным. Белые люди просто вызывают нужные методы из специально созданной библиотеки, а потом уничтожают их для очистки памяти. И никаких проблем. Что, приложение занимает больше места на диске? аж на 3%? Какой ужас.
>была кретиническая мода на уменьшение числа методов и классов в приложении, ну так это нифига не улучшало ситуацию, а код становился запутанным.
Блядь, совсем недавно была(уже чуть пошла на спад) мода на УВЕЛИЧЕНИЕ числа классов и методов. Код от этого становился действительно простым, даже слишком, ибо большинство методов и куча классов, по сути, нихуя не делали. А вот проект становился неебически сложным, ибо понять, где в этом ебанном месиве из 100500 классов делается то, что тебе нужно, а не проксируется очередной бессмысленной хуете, поднятой в виде интерфейса через фабрику - это полный пездец. Это в джаве, и мода эта пошла со Спрингом и засильем тестов. Сейчас народ массово валит от этого бреда на скалку или другие технологии, потому что за эти годы наваяли монстров с огромным количеством кода, конфигов, которые нихуя не конфигурируют, тестов, которые нихуя не тестируют, библиотек, которые используются три раза и на 0.0001% от их возможности и все в этом духе. Исходник проекта после подтягивания зависимостей весит гиг, а это всего-лишь очередная блядская система отчетов и ведения записей очередной затрапезной буржуйской больнички.
Блядь, совсем недавно была(уже чуть пошла на спад) мода на УВЕЛИЧЕНИЕ числа классов и методов. Код от этого становился действительно простым, даже слишком, ибо большинство методов и куча классов, по сути, нихуя не делали. А вот проект становился неебически сложным, ибо понять, где в этом ебанном месиве из 100500 классов делается то, что тебе нужно, а не проксируется очередной бессмысленной хуете, поднятой в виде интерфейса через фабрику - это полный пездец. Это в джаве, и мода эта пошла со Спрингом и засильем тестов. Сейчас народ массово валит от этого бреда на скалку или другие технологии, потому что за эти годы наваяли монстров с огромным количеством кода, конфигов, которые нихуя не конфигурируют, тестов, которые нихуя не тестируют, библиотек, которые используются три раза и на 0.0001% от их возможности и все в этом духе. Исходник проекта после подтягивания зависимостей весит гиг, а это всего-лишь очередная блядская система отчетов и ведения записей очередной затрапезной буржуйской больнички.
Чуваак. Я тебя сильно опечалю, если скажу, что в 95% кода винды юнит-тестами и не пахло? А там, где есть - это в основном новые тулзы на дотнете.
Чтобы написать коммент, необходимо залогиниться
