Сообщение Re[5]: Юнит тестирование "памяти" от 20.04.2015 13:28
Изменено 20.04.2015 13:32 Tesh
Здравствуйте, fedor.reznik, Вы писали:
FR>С другой стороны, я участвовал как минимум в трех коммерчески успешных проектах, в которых, не было тестов. Совсем. От слова вообще.
FR>Значит ли это, что тесты писать — это преждевременно себя напрягать? Наверное, нет.
Если там не было тестов, значит это не было экономически обосновано. Тесты не бесплатны и требуют время как на написание, так и на поддержку.
FR>Далее, если проблема возникла, то обычно ее фиксить дорого (потому что надо срочно) и, за частую, поздно.
FR>Поэтому очевидные сценарии, имхо, имеет смысл профилировать перед каждым релизом — Вы же не выпускаете продукт без тестирования?
Для этого существуют приемочное и нагрузочное тестирования.
FR>И dotMemoryUnit — это такое средство автоматизировать этот процесс, а вовсе не yet another profiler)
FR>И именно в этом смысле, как мне кажется, он имеет гораздо более широкое применение.
Обычные тесты помогают убедиться в том, что код работает корректно с точки зрения бизнес-логики или архитектуры. Это по идее чаще востребовано, чем покрытие кода тестами для ответа на вопрос "а не течет ли чего" или "эффективно ли выделяется память". Такие тесты тоже могут пригодиться, но не думаю что они будут столь же широко распространены как и тесты логики.
FR>С другой стороны, я участвовал как минимум в трех коммерчески успешных проектах, в которых, не было тестов. Совсем. От слова вообще.
FR>Значит ли это, что тесты писать — это преждевременно себя напрягать? Наверное, нет.
Если там не было тестов, значит это не было экономически обосновано. Тесты не бесплатны и требуют время как на написание, так и на поддержку.
FR>Далее, если проблема возникла, то обычно ее фиксить дорого (потому что надо срочно) и, за частую, поздно.
FR>Поэтому очевидные сценарии, имхо, имеет смысл профилировать перед каждым релизом — Вы же не выпускаете продукт без тестирования?
Для этого существуют приемочное и нагрузочное тестирования.
FR>И dotMemoryUnit — это такое средство автоматизировать этот процесс, а вовсе не yet another profiler)
FR>И именно в этом смысле, как мне кажется, он имеет гораздо более широкое применение.
Обычные тесты помогают убедиться в том, что код работает корректно с точки зрения бизнес-логики или архитектуры. Это по идее чаще востребовано, чем покрытие кода тестами для ответа на вопрос "а не течет ли чего" или "эффективно ли выделяется память". Такие тесты тоже могут пригодиться, но не думаю что они будут столь же широко распространены как и тесты логики.
Здравствуйте, fedor.reznik, Вы писали:
FR>С другой стороны, я участвовал как минимум в трех коммерчески успешных проектах, в которых, не было тестов. Совсем. От слова вообще.
FR>Значит ли это, что тесты писать — это преждевременно себя напрягать? Наверное, нет.
Если там не было тестов, значит их наличие не было экономически обосновано. Тесты не бесплатны и требуют время как на написание, так и на поддержку.
FR>Далее, если проблема возникла, то обычно ее фиксить дорого (потому что надо срочно) и, за частую, поздно.
FR>Поэтому очевидные сценарии, имхо, имеет смысл профилировать перед каждым релизом — Вы же не выпускаете продукт без тестирования?
Для этого существуют приемочное и нагрузочное тестирования.
FR>И dotMemoryUnit — это такое средство автоматизировать этот процесс, а вовсе не yet another profiler)
FR>И именно в этом смысле, как мне кажется, он имеет гораздо более широкое применение.
Обычные тесты помогают убедиться в том, что код работает корректно с точки зрения бизнес-логики или архитектуры. Это по идее чаще востребовано, чем покрытие кода тестами для ответа на вопрос "а не течет ли чего" или "эффективно ли выделяется память". Такие тесты тоже могут пригодиться, но не думаю что они будут столь же широко распространены как и тесты логики.
FR>С другой стороны, я участвовал как минимум в трех коммерчески успешных проектах, в которых, не было тестов. Совсем. От слова вообще.
FR>Значит ли это, что тесты писать — это преждевременно себя напрягать? Наверное, нет.
Если там не было тестов, значит их наличие не было экономически обосновано. Тесты не бесплатны и требуют время как на написание, так и на поддержку.
FR>Далее, если проблема возникла, то обычно ее фиксить дорого (потому что надо срочно) и, за частую, поздно.
FR>Поэтому очевидные сценарии, имхо, имеет смысл профилировать перед каждым релизом — Вы же не выпускаете продукт без тестирования?
Для этого существуют приемочное и нагрузочное тестирования.
FR>И dotMemoryUnit — это такое средство автоматизировать этот процесс, а вовсе не yet another profiler)
FR>И именно в этом смысле, как мне кажется, он имеет гораздо более широкое применение.
Обычные тесты помогают убедиться в том, что код работает корректно с точки зрения бизнес-логики или архитектуры. Это по идее чаще востребовано, чем покрытие кода тестами для ответа на вопрос "а не течет ли чего" или "эффективно ли выделяется память". Такие тесты тоже могут пригодиться, но не думаю что они будут столь же широко распространены как и тесты логики.