Это что, аффтар топика в IT работает? Какой ужас! :))

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

кстати, у мелгомягких очень хорошие книги по тестированию софта - посмотри на серию best practices

думать как от этого избавиться (от влияния внешних вещей)
------
По задаче - невозможно. Можно найти ограничения и предложить частное
решение, но это уже другая задача.
Брррр,
------
Согласен. Тем не мение - требовалось решение. Вроде сделал.
у меня у самого есть расширяемая система с собственным языком
-----
Ну еще одно усилие - входных языков - два и оба не до конца определены
и, по определению, не могут быть определены. И результат как перемножение...
там тестируются все элементы языка, и их сочетания в применении к
определенным входным данным - как правильным, так и неправильным.
------
Это - легко... Написал грамматику, определил рекцию для свертки каждой
продукции и все работает.
Правда не понимаю смысла тестирования всех элементов - при
неоднозначностии грамматики частичные тесты пойдут на ура, но не дадут
результата.
Полный же тест возможен только для очень ограниченных языков.

посмотри на серию best practices
-----
Если руки дойдут.
Для меня сейчас критичнее освоить .Net 4.0 и кучу его новых фич.
Плюс SharePoint...
Плюс SISC...
Плюс...
А не послать ли мне все это нафиг и не уехать ли к теплому морю?

ну почему-то большинство языков программирования имеют тесты, значит не только для ограниченных языков :-)

большинство языков программирования имеют тесты
-----
И что они тестируют? Не написал ли прогер глупости? Это - да, это тесты...
Только Я говорил не об этом, а об определении языка и подготовке к его
обработке. Разница в том, что там нужно доказывать что язык определен
корректно - тесты не дадут результата по определению...
значит не только
------
Это тебя немного не туда занесло. Бо, если язык рекурсивный, то все
возможные сентенции определить и протестировать невозможно.
Это базис. ТФЛ.
Ну а не рекурсивные и есть весьма ограниченные. Т.е. какой-нибудь
пасивный ини-файл можно парсить без проблем, но для ХМЛного с
перекрестными ссылками уже придется думать. Запихни в тот же ХМЛ
еще какую-нибудь логику, дающую инфинитивность вариаций, и все
станет на места.

у меня язык рекурсивный, с условными выражениями и т.п. все покрыто тестами на 95 процентов, и все работает как надо в промышленной эксплуатации. Если конечно пользователь не напишет глупостей в программе на этом языке

все покрыто тестами на 95 процентов
-----
Ну не знаю. При такой задаче Я бы больше занимался поиском обоснований
работоспособности, чем тестами. Бо, затраты на них отличаются более чем
два порядка... и нет гарантий что все тип-топ.
...и все работает как надо в промышленной эксплуатации. Если конечно...
-----
Примерно так же было при разработке Алгола. Группа разработчиков допустила
неоднозначность в определении языка... а так - все работало... пока не случалось
споткнуться об эту неоднозначность.
Работает - хорошо. Юзер знает ограничения - хорошо. Но на этом уровне стоит
доказывать, что там действительно все хорошо. Тесты этого не дают.

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

А что такого? Не она же кодит ;)

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

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

запускаешь программу и потом глазами просматриваешь лог?
------
Проверяю ожидаемый результат. Логи и остальное - если результат не совпадает.
Обычно - все в ООП и найти баг - не проблема... ну за исключением тех случаев,
когда он не в коде...
пишу тесты на более-менее сложные куски кода
------
Я уже выше просил показать какой-нибудь не тривиальный код и его тесты.
если я вернусь к нему через полгода, я могу что-то напортачить исправляя его
------
Напортачить можно в любом случае. Потому - что-то проверяется локально, что-то
- по полученному результату. В полиси прописано - коммитить работающий код.

сложный код к сожалению весь под NDA

- как всегда. А простой - не покажет преимуществ.

Синтетический пример на основе, нельзя изобрзить?

где время взять для синтетических примеров? да и их полно в книжках по тестированию...

Только не говори, что ты никогда не писал юнит-тестов.