On 12.07.2012 02:55, Stanislav Maslovski wrote: > On Wed, Jul 11, 2012 at 08:35:48PM +0400, "Артём Н." wrote: >> On 11.07.2012 04:18, Stanislav Maslovski wrote: >>> Они есть. Этого уже достаточно. >> Недостаточно. Достаточно было бы, если бы их на практике было просто >> применить... Часто ли это применяется и просто ли? > Применяется в mission-critical systems, насколько часто и насколько > просто - вопрос скорее к тем, кто этими системами плотно занимается. Эм... Точно. Спрошу.
>>> Нет. Повторюсь: построение *полного* теста в общем случае эквивалентно >>> решению >>> исходной программной задачи. Как ты собираешься доказывать правильность >>> самого теста? Ещё одним тестом? И так до бесконечности? >> М... Ну да. Про тест я не подумал. Но, если тест - просто тупой перебиратель >> результата..? > В таком случае, и сама программная задача тупа в той же мере, в какой > туп ее *полный* тест. Я подумал о следующем варианте... 1. Есть программа, которая получает данные (к примеру, пакет фиксированного размера из сети). 2. Она обрабатывает данные (это чёрный ящик), в зависимости от того, что поступило на вход и того, что поступало ранее (но память ограничена). 3. При её запуске состояние всегда одинаковое (не ведётся база или всегда обнуляется). 4. На выходе - пакет. 5. Программа не учитывает временные характеристики, поступающих данных. Пакет - число определённой разрядности. Длина, в данном случае, фиксирована. Обработка может быть сколь угодно сложной (например, это модуль ЦОС, принимающий данные от АЦП). Тест - это простая таблица, в общем случае. В случае ограниченной памяти (а для тестирующего, функция - "белый ящик" и все ограничения известны), достаточно просто составить цепочки значений входов. И проверить, что будет на выходе после каждого такта. В принципе... Такую функцию возможно заменить таблицей. Но ведь не всегда это может быть возможно (к тому же, составление таблицы возможно автоматизировать). Хотя, конечно, уж больно частный случай. :-| И сомнительно это. >>>>> Вот тебе элементарный пример: докажи теорему Пифагора *тестами* =) >>>> Возможно повысить уверенность в том, что алгоритм доказательства теоремы >>>> реализован правильно, используя тесты. >>> Это ещё что за новая сущность? "алгоритм доказательства теоремы"? >> Я именно про конкретный случай. Есть доказательство по опр. алгоритму. >> Тесты позволят повысить уверенность в нём. > Я - пас :) Желающие продолжить - велкам. Ну, хорошо. :-D В общем-то, про тесты, во многом я согласен, просто поспорить охота. Тут, кажется, есть достаточно определённое решение: 1. Естественно, никакого "доказательства тестами" нет (я про такое и не писал), если тесты не могут покрыть всю область определения. 2. Писать тесты лучше, чем не писать тесты. 3. У тестов есть один серьёзный минус: сложная задача требует сложных тестов. И, как выясняется, объём тестов сопоставим с объёмом задачи, а в некоторых случаях, даже больше. 4. Пункт 3 заставляет серьёзно подумать над пунктом 2. 5. Если возможно однозначно доказать корректность, то тест проще выкинуть, чем поддерживать. Да он и не требуется. Но смущают некоторые вещи: 1. TDD. Ведь оно существует? Вероятно, оно создавалось для больших проектов. Где-нибудь используется? 2. Но ведь модульное тестирование продвигается и приветствуется... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ffee7a4.2040...@yandex.ru
