Язык программирования, предназначенный для проверки

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

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

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

Как насчет объектно-ориентированного программирования? Такие вещи, как инъекция зависимостей, и насмешливые библиотеки действительно помогли TDD, wouldn Эти методы выигрывают от того, чтобы быть частью дизайна языка? Я смотрю вокруг, а языки с богатыми метамоделями, как правило, позволяют использовать DSL-подобные API, которые должны быть написаны на целевом языке. Эти библиотеки строятся поверх этого, почему бы не потянуть эти вещи на язык?

Я нахожу, что это сообщение в блоге, на которое ссылается Джеймс Блэк, действительно имеет к этому хороший смысл.

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

Я чувствую необходимость писать тесты для кода, который я пишу очень часто.

Так же часто, эта проблема мешает экологическим ограничениям, поэтому я заканчиваю не записывая эти тесты.

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

Ответ 1

Google работает над noop как язык (OOP, Java), созданный для создания кода, который всегда можно проверить.

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

Язык также явно запрещает некоторые конструкции, которые усложняют проверку кода, например, статику.

Ответ 2

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

Ответ 3

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

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

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

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

Eiffel, где "дизайн по контракту" побуждает вас ставить в свой код предварительные условия и постусловия, и они тестируются. Я считаю Eiffel успешно развернутым языком.
Racket (ранее PLT Scheme), где проводятся интересные исследования в контрактах и тестировании; интересные биты состоят в том, что когда тест не удается, язык говорит вам не только о нарушении контракта, но и о том, какую часть кода следует обвинять. Для получения дополнительной информации, google для Robby Findler и для "вины". Racket - это язык исследований, но это расширение Scheme, которое довольно широко используется для нишевого языка.
Ana, расширение Ada, сделанное Дэвидом Лакхемом и его учениками, которое поддерживало некоторые испытания. Насколько я знаю, Ана никогда не выходила за рамки исследования.

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

Тестирование - это, безусловно, ДОПОЛНИТЕЛЬНАЯ часть процесса, как и все на Python, на самом деле очень мало на вас навязывается. Тем не менее, я бы сказал, что любой язык, который нашел способ заставить вас писать тесты, а не ENCOURAGING таким хорошим поведением, на самом деле является примером того, как законодательно применять методы кодирования, которые связаны с обратными эффектами.

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

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

UPDATE:

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

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

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

Ответ 12

Я думаю, что Ruby находится там, где он находится.

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

Это не столько о написании "тестов", сколько о том, чего хочет клиент, и о том, какие инструменты используют в качестве спецификации для создания.

Как и rspec, shoula, машинист, подделка, а остальное делают Ruby реальным соображением, если это то, где вы заинтересованы.

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

Ответ 13

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

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

Ответ 14

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