Здравствуйте, red_dragon, Вы писали:

_>Проведение рефакторинга системы без юнит-тестов — это bugs*bugs при котором bugs -> infinity

Несмотря на то, что я за юнит тесты, но данное высказывание более чем спорно

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>О да. Просвети нас, чем же именно уникален Янус?

А кто сказал, что он уникален?

Здравствуйте, Mirrorer, Вы писали:

M>Я учавствовал в проекте, в котором юнит тесты начали писать на этапе активного багфиксинга. Процент выловленных багов благодаря юнит тестам был где-то 20%. Я вполне допускаю что для другого проекта этот показатель мог быть как 60% так и 0. А вот для нового проекта мне почему-то кажется что использование юнит тестов будет эффективным по умолчанию. Может я ошибаюсь

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, AndrewVK, Вы писали:

AVK>>Янус спроектирован таким образом. Только проблема там в другом месте.

ANS>О да. Просвети нас, чем же именно уникален Янус?

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Mirrorer, Вы писали:

M>>Я учавствовал в проекте, в котором юнит тесты начали писать на этапе активного багфиксинга. Процент выловленных багов благодаря юнит тестам был где-то 20%. Я вполне допускаю что для другого проекта этот показатель мог быть как 60% так и 0. А вот для нового проекта мне почему-то кажется что использование юнит тестов будет эффективным по умолчанию. Может я ошибаюсь

AVK>Ну а у меня есть один относительно небольшой проект — библиотечка. Я его специально изначально писал с хорошим покрытием юнит-тестами. В результате сил было на них убито масса (особенно доставало то, что после масштабного рефакторинга ломалась сразу куча тестов, к самому рефакторингу прямого отношенияы не имеющая). При этом эти самые юнит-тесты поймали 1 (одну) ошибку.

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

Здравствуйте, prVovik, Вы писали:

V>Здравствуйте, red_dragon, Вы писали:

_>>Проведение рефакторинга системы без юнит-тестов — это bugs*bugs при котором bugs -> infinity

V>Несмотря на то, что я за юнит тесты, но данное высказывание более чем спорно

Делали рефакторинг без юнит-тестов?

Я делал В итоге что-бы все заработало как надо, потратил массу времени, ну и чистота кода оставляет желать лучшего

Здравствуйте, AndrewVK, Вы писали:

AVK>А кто сказал, что он уникален?

Хорошо. Тогда скажи в каком именно другом месте проблема.

Здравствуйте, red_dragon, Вы писали:

_>Делали рефакторинг без юнит-тестов?

_>Я делал В итоге что-бы все заработало как надо, потратил массу времени, ну и чистота кода оставляет желать лучшего

это ни о чем не говорит. разве что о вашей квалификации.

Здравствуйте, red_dragon, Вы писали:

_>Делали рефакторинг без юнит-тестов?

_>Я делал В итоге что-бы все заработало как надо, потратил массу времени, ну и чистота кода оставляет желать лучшего

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

Здравствуйте, degor, Вы писали:

D>Здравствуйте, red_dragon, Вы писали:

_>>Делали рефакторинг без юнит-тестов?

_>>Я делал В итоге что-бы все заработало как надо, потратил массу времени, ну и чистота кода оставляет желать лучшего

D>это ни о чем не говорит. разве что о вашей квалификации.

я вам улыбаюсь

Здравствуйте, Andrei N.Sobchuck, Вы писали:

AVK>>А кто сказал, что он уникален?

ANS>Хорошо. Тогда скажи в каком именно другом месте проблема.

Место называется GUI

Здравствуйте, prVovik, Вы писали:

V>А если бы ты со своей библиотечкой решил присоединиться к многочисленно когорте программистов-ядерщиков, и из-за этого бага взорвался бы ядерный реактор?

Ах да, про программистов АЭС то я и забыл.

Здравствуйте, red_dragon, Вы писали:

_>Делали рефакторинг без юнит-тестов?

Я делаю регулярно. Ужасов не замечено.

Здравствуйте, AndrewVK, Вы писали:

AVK>Место называется GUI

Согласен, если приложение состоит только из гуя и совершенно не содержит логики, то тут юнит тесты не помогут.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Mirrorer, Вы писали:

M>>Я учавствовал в проекте, в котором юнит тесты начали писать на этапе активного багфиксинга. Процент выловленных багов благодаря юнит тестам был где-то 20%. Я вполне допускаю что для другого проекта этот показатель мог быть как 60% так и 0. А вот для нового проекта мне почему-то кажется что использование юнит тестов будет эффективным по умолчанию. Может я ошибаюсь

AVK>Ну а у меня есть один относительно небольшой проект — библиотечка. Я его специально изначально писал с хорошим покрытием юнит-тестами. В результате сил было на них убито масса (особенно доставало то, что после масштабного рефакторинга ломалась сразу куча тестов, к самому рефакторингу прямого отношенияы не имеющая). При этом эти самые юнит-тесты поймали 1 (одну) ошибку.

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

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Andrei N.Sobchuck, Вы писали:

AVK>>>А кто сказал, что он уникален?
ANS>>Хорошо. Тогда скажи в каком именно другом месте проблема.
AVK>Место называется GUI

И что в нем такого уникального? Существуют системы тестирования гуев, очень неплохо
себя оправдывают, например в одном проекте на netbeans использовался http://xtest.netbeans.org/,
по багтраку примерно 30% ошибок гуевых им выловлено.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

AVK>>Место называется GUI

ANS>Согласен, если приложение состоит только из гуя и совершенно не содержит логики, то тут юнит тесты не помогут.

Не, ну Янус конечно кое какую логику содержит. Но, вот беда, львиная доля багов в нем приходится как раз на GUI.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, aka50, Вы писали:

AVK>>>А что такое юниты в твоем понимании? И как определить их наличие/отсутствие?
A>>Это примерно то, на что распадается приложение, которое проектируется с использованием паттерна IoC. Если приложение не проектировалось изначально под IoC, прикрутить потом IoC — себе дороже.

AVK>Да, ребяты. Вопросов больше не имею.
А расшифровать? А то ощущение что "послали"...

Здравствуйте, aka50, Вы писали:

A>И что в нем такого уникального?

А кто сказал, что оно уникально?

A> Существуют системы тестирования гуев, очень неплохо

Ага, Существуют.

Здравствуйте, bkat, Вы писали:

B>Кстати, а почему возникла необходимость в масштабном рефакторинге?

Потому что подход к разработке такой.

B>Может сначала стоит потратить время на то, чтобы продумать интерфейсы.

Как все просто

B>Если интерфейсы потом сильно меняются, то это всегда очень дорого.

Это понятно. Речь о другом — юнит тесты это все удорожают в два раза.

B>Всю документацию, и всех, кто интерфейсы пользует.

Это если документация и все на тот момент существуют.

B>Юнит-тесты тут совсем не причем.

Причем причем.

B> Юнит-тесты — это всего лишь один из многих, кто пользуется интерфейсами твоей библиотеки.

На этапе начальной разработки это не одни из многих, а единственный потребитель.