SlivaВезде ли нужны тесты?
Правильнее спросить иначе: какие тесты нужны в конкретном случае.

Тесты нужны, в общем, везде. Но при нехватке опыта к ним чаще всего подходят неправильно, и как результат - без тестов вышло бы лучше.

SlivaМожет, в виду того, что я не особо вижу целесообразность в создании тестов я так и не пишу их. Ну и в компании про тесты никто ни слухом, ни духом. Проекты корпоративные.
Я... не уверен, что Вам стоит это менять. Сдвигать глыбу "мы так привыкли работать" - тяжело, а когда Вы сами не уверены, не видите целесообразности итп - результат нетрудно предсказать.

F#Не везде. Иногда это дорого.
Не согласен.

Дорого - это означает неправильную организацию тестов. Чаще всего - излишний спуск в детали реализации, вторая по распространённости причина - технологические бредни (скажем, попытка "по канонам" выстраивать для каждого независимое окружение). Это не значит, что тесты не нужны, это значит, что их нужно строить адекватно задаче.

F#softwarerДорого - это означает неправильную организацию тестов.
Если речь идет о юнит тестах, то да. В других случаях может зависеть от окружения.
Скажу так: вопрос в том, с чем сравнивать это "дорого". Для оценки масштаба можно взять следующие вещи: стоимость ручного тестирования, стоимость проекта в целом, стоимость отсутствия тестирования (то есть проявившихся ошибок). Так вот, я бы сказал, адекватно выстроенные автоматические тесты в любом случае "не дороги" относительно этих показателей. Во всяком случае, исключений я не встречал.

SlivaСдвигать глыбу не придется.
Не уверен, потому как тесты не писал.
Могу рассказать, как я сам начал их писать.

Первый раз это было лет двадцать назад. Я тогда написал парсер SQL-запросов, предназначенный брать произвольный запрос, бить его на части и позволять в дальнейшем скомпоновать эти части с модификациями (скажем, добавить условия в where). И чтобы понять, правильно ли он работает, я написал для него штук тридцать ожидаемых комбинаций вход-выход и сделал подпрограмму, которая их проверяла. И обнаружил, что это удобно, особенно когда парсер начал дописываться и переписываться.

Потом я долго занимался оптимизацией одного класса-контейнера. И написал для него несколько "проверочных испытаний", засекавших время выполнения той или иной кучи операций.

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

Ну а дальше... дальше, собственно, я уже чувствовал, какую пользу извлекаю из этих тестов. Особенно при традиционном для наших контор отсутствии тестировщиков.

Cpt. GrayСделал для него простенький тест и откопал интересный момент, что я забыл учесть регистр, и из-за этого не совпадали суммы букв (прописные и заглавные)
Бывает веселее.

Помнится, я на Яве написал некую вещь, использовавшую список. По всему надо было использовать ArrayList. Я подумал: а может ли случиться так, что в некоторых условиях LinkedList будет лучше? И чисто из пижонства написал тест, который сравнивал по времени оба варианта и ругался, если ArrayList оказывался медленнее. Так вот: этот тест сразу же сработал и сказал, что LL в 36 раз быстрее

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

sphinx_mvЕсли, конечно, спецификация не слишком часто меняется - это непосредственно ведет к переписыванию соотвествующих юнит-тестов
Регулярное переписывание тестов - это верный признак того, что тестируется не то, что нужно. Это значит, что тесты излишне опущены в детали реализации.

sphinx_mvКак резюме: использование или не использование юнит-тестов крайне неоднозначно. Юнит-тесты "в-целом" хорошо... Но могут быть и исключения... :(
Я скажу иначе. Автоматические тесты - хорошо. Но далеко не всегда их разумно делать "юнит".