Язык программирования, разработанный, чтобы быть тестируемый [закрытый]

Когда я поигрался с концепцией Zero Button Testing , естественным образом возник язык принудительного тестирования / IDE. Это просто игрушечный язык, но идея заложена в нем: любая строка, не охваченная тестами, отображается желтым цветом, а любые функции с любыми непроверенными строками могут считаться неработоспособными (хотя проект никогда не заходил так далеко) .

Идея здесь в том, что тесты встроены непосредственно в процедуру, которую они тестируют; он работает в таком масштабе, но я сомневаюсь в его максимальной масштабируемости.

Я никогда не видел ничего, что бы тестирование не являлось необязательным, встроенным или предполагаемым, но самый «вспыльчивый» язык, который я видел, - это Ruby - он поставляется с инструментами модульного тестирования из коробки, его легко тестировать и имитировать, потому что типы являются динамическими, и сообщество в целом хорошо осведомлено о методах тестирования (с множеством доступных инструментов TDD и BDD). Хотя странную нехватку средств покрытия кода замечаю.

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

http://beust.com/weblog2/archives/000522.html

ОБНОВЛЕНИЕ:

В упомянутом выше блоге рассматривается вопрос для этого сообщения, так как заголовок следующий:

Должны ли языки программирования поддерживать модульное тестирование изначально?

Итак, есть комментарии по поводу тестирования на других языках.

Я думаю, что Руби там, где она есть.

Такие инструменты, как огурец . Когда вы пишете пользовательские истории на почти естественном языке, понятном деловым людям, а затем фактически их передаете, это замечательно в качестве «инструмента TDD».

Речь идет не столько о написании «тестов», сколько о том, чтобы начать с того, что хочет заказчик, и иметь инструменты, которые используют это в качестве вашей спецификации для построения.

Так же, как rspec , плеча, машинист, фейкер и другие делают Ruby реальным объектом внимания, если это то, что вас интересует.

Я бы также сказал, что возможность создавать свой собственный DSL ставит динамические языки на передний план в этой области.

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

Spring Framework сосредотачивается на внедрении зависимостей и создании легко тестируемых простых старых объектов Java (POJO)

Хорошей идеей может стать язык, который поддерживает проектирование по контракту, например Eiffel (или iContract в Java). Таким образом, вы сможете достаточно легко протестировать предварительные и последующие условия, а также инварианты класса.

Кроме того, TDD в значительной степени нейтрален к языку.

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

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

Есть много конкретных примеров реальных проектов, которые являются крупными, используются большим количеством людей, имеют большие наборы тестов, являются практическими примерами хороших результатов тестирования программного обеспечения, и те, с которыми я знаком больше всего, написаны на Python. Однако, возможно, люди из SQLite (C/C++) тоже заслуживают некоторой похвалы за создание одного из самых тщательных тестовых наборов во всем мире открытого кода.

Тестовые пакеты на Python (как и весь прикладной код на Python) обычно короче, проще в написании и легче в чтении, чем на любом другом языке, который я использовал. И все же, хотя я не думаю, что C/C++, в частности, является очень легким языком для написания тестов, и что, скорее всего, страсть и техническое мастерство разработчиков проекта SQLite, а также необходимость иметь возможность доверять их работе привели к написанию большого, тщательного, эффективного набора тестов на C++, и ничего общего с самим языком C++.

Итак, Python помогает вам, облегчая написание приложений, давая вам время на написание тестов, вот и все. Но там, где в C++ не хватает функций, помогающих писать тесты, и требуется больше времени, чтобы создать то же самое на C++, все равно некоторые разработчики проявляют мастерство и преданность делу и делают это так или иначе, любой ценой времени и усилий.

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

Тестирование - определенно ВАРИАНТНАЯ часть процесса, как и все в Python, очень мало того, что на самом деле навязывается вам. Однако я бы сказал, что любой язык, который нашел способ заставить вас писать тесты, а не поощрять такое хорошее поведение, на самом деле является примером попытки законодательного регулирования практики кодирования, что неизбежно приведет к обратному результату.

Я откровенно не понимаю, как можно спроектировать язык таким образом, чтобы заставить вас тестировать, не превращая язык в совершенно бесполезную академическую подстилку. Как и многие другие, я считаю, что удобство использования языка для выполнения реальной работы на реальной работе гораздо важнее, чем понятия формализма и доказуемой корректности из башни из слоновой кости.

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

Спрашивайте не о том, что вы можете сделать для своих формализмов, а о том, что могут сделать ваши формализмы, чтобы вернуться на землю.

Какие языки программирования тестируемы по дизайну?

У меня трудные времена с этим вопросом, потому что я не уверен, что значит для языка быть тестируемым по дизайну. Тестирование обычно связано с инструментами и статическим анализом, а не с дизайном языка.

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

По этим критериям, Я знаю три:

• Eiffel, где "проектирование по контракту" поощряет вас вставлять в код предварительные и последующие условия, и они тестируются. Я считаю Eiffel успешно внедренным языком.

• Racket (бывший PLT Scheme), где проводятся интересные исследования в области контрактов и тестирования; интересно то, что когда тест не проходит, язык не только сообщает вам, что контракт был нарушен, но и определяет, какую часть кода следует винить. Для получения более подробной информации найдите в Google Робби Финдлера и слово "blame". Racket - это исследовательский язык, но он является расширением Scheme, который довольно широко используется для нишевого языка.

• Ana, расширение Ada, сделанное Дэвидом Лакхэмом и его студентами, которое поддерживало некоторое тестирование. Насколько я знаю, Ana никогда не выходила за рамки исследовательской стадии.

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

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