Re: Несколько вопросов вразброс
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. Но ведь модульное тестирование продвигается и приветствуется...
Reply to: