Сон Веры ПавловныЕвгенийВdepend86,
Это как за бутылкой водки поехать.
Из Зеленограда в Москву.
Через Казань.
На большегрузном КамАЗе.
Вместо того, что бы пешком сгонять через дорогу в продуктовый.
Или как про факториал .

Раз зашёл такой разговор, позвольте моё мнение хорошо обрисованное здесь

why most unit testing is waste

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

fsharp_fsharpmikronпропущено...


Раз зашёл такой разговор, позвольте моё мнение хорошо обрисованное здесь

why most unit testing is waste

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

никто не отменяет полезность функциональных тестов. но у юнит-тестов другое назначение . по аналогии с машиной: один разработчик протестировал, что отверстия под дверь сделаны правильно (саму дверь при этом не надо прикручивать, и не надо звать покупателя, чтобы он её тестировал на "открыть/закрыть"). как он это сделал? протестировал (линейкой). откуда у него способ проведения измерения? из спецификации на дверь. кузов пришел по конвейеру (исходники закоммитили в репозиторий) к другому разработчику, который при помощи кувалды сминает люминий (пишет какой-то говно код). все дверь уже не прикрутить. но для этого опять не надо саму дверь (и тем более покупателя-тестировщика) - достаточно того, что тест (измерение линейкой) красный
Вот именно здесь сравнение не корректно , т.к. предполагается что тестируется отдельная деталь на соответствие спецификации. При этом спецификация одна а детали представляют массовое производство. В софтварной индустрии это по большому счёту не так. Исключения - единицы, как то компиляторы. Их можно условно проверить на соответствие стандарту. В случае автора спецификации нет. Если бы была, то во первых была бы на его конкретный код малополезна, во вторых, не возникало бы вопросов, что тестировать - на соответствие спецификации.
Софтварный продукт по сути представляет мануфактурное производство, т.к. делается один раз под конкретней случай. Автор кода сам в определённой степени выбирает архитектурный дизайн и определяет интерфейсы. Возводить его видение в спецификацию можно, но какой в этом прок. Софт не будет делаться массово (или даже дважды) по этой спецификации. Скорее всего изменятся функциональные требования ко всему софту, и в таком случае надо или пересматривать спецификации или не трогать код.

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

Перегонщик перекупкиmikronпропущено...

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

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

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