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

Question

Раньше я много занимался веб-программированием на Rails (до PHP), прежде чем начал изучать компьютерную инженерию.

С тех пор я проделал большую школьную работу в C и некоторые личные вещи в Objective-C (Mac).Я научился любить статическую типизацию.

Но теперь мне нужно заняться профессиональной веб-разработкой (фрилансингом) и снова заняться Rails.Я нахожу действительно раздражающим писать несемантические тесты проверки типов.Я получал их бесплатно от компиляторов C и Objective-C.Мне нравилось нажимать на Build и заставлять систему проверять весь мой код, чтобы увидеть, что A может вызывать B, B может вызывать какую-то непонятную библиотеку C и т. Д. Все, что мне нужно было сделать, это проверить семантику.Но с Rails я компилятор.:(

Кто-нибудь ходил по этому же пути? Являются ли мои единственные варианты веб-разработки ASP.NET MVC с C # и структурой Java + x? Ищете некоторые предложения или даже сочувствие ...: P

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

Спасибо!

edit:

Я последовал предложению PST и посмотрел на ScalaЧитая книгу «Программирование на Scala», написанную создателем языка Мартином Одерским, я наткнулся на этот фрагмент текста, который во многом выражает мои опасения и немного больше. Очень интересное чтение.

Взят со страницы52 из Мартина Одерского по программированию в Scala:

Статическая типизация Scala

Статическая система типов классифицирует переменные иd выражений в соответствии с типами значений, которые они хранят и вычисляют.Scala выделяется как язык с очень продвинутой системой статических типов.Начиная с системы вложенных типов классов, очень похожих на Java, она позволяет параметризировать типы с помощью обобщенных типов, объединять типы, используя пересечения, и скрывать детали типов, используя абстрактные типы.Они дают прочную основу для создания и компоновки ваших собственных типов, так что вы можете создавать интерфейсы, которые одновременно безопасны и гибки в использовании.

Если вам нравятся динамические языки, такие как Perl, Python, Ruby,или Groovy, вам может показаться странным, что система статических типов Scala указана в качестве одной из ее сильных сторон.В конце концов, некоторые считают, что отсутствие статической системы типов является главным преимуществом динамических языков.Наиболее распространенные аргументы против статических типов состоят в том, что они делают программы слишком многословными, мешают программистам выражать себя так, как они хотят, и делают невозможными определенные шаблоны динамических модификаций программных систем.

Однако зачастую эти аргументы не приводятсяпротив идеи статических типов в целом, но против конкретных систем типов, которые воспринимаются как слишком многословные или слишком негибкие.Например, Алан Кей, изобретатель языка Smalltalk, однажды заметил: «Я не против типов, но я не знаю ни одной системы типов, которая не является полной болью, поэтому я все еще люблю динамическую типизацию».

Мы надеемся убедить вас в этой книге, что система типов Scala далеко не «полная боль». На самом деле, она хорошо решает две из обычных проблем статической типизации: многословия избегают благодаря выводу типа и гибкостидостигается путем сопоставления с образцом и нескольких новых способов написания и составления типов.С учетом этих препятствий можно лучше оценить классические преимущества систем статического типа.Среди наиболее важных из этих преимуществ - проверяемые свойства программных абстракций, безопасный рефакторинг и улучшенная документация.

Проверяемые свойства

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

Другие виды ошибок не обнаружены современными системами статического типа. За Например, они обычно не обнаружат не завершающие функции, массив границы нарушения, или деления на нуль. Они также не обнаружат, что ваша программа не соответствует спецификация (при условии, что есть Спец это!). Системы статического типа поэтому были отклонены некоторыми как не очень полезно. Аргумент выходит, что, поскольку такие системы типов могут обнаруживать только простые ошибки, тогда как модульные тесты дают более обширный охват, зачем возиться со статическими типами совсем?

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

Безопасный рефакторинг

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

Документация

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

Answer 1

Это одна из моих «жалоб» на динамические языки.Я хочу проверять семантику, а не ошибки типа ;-) При этом, хорошая инфраструктура / настройка тестирования действительно необходима во всех нетривиальных ситуациях, и хорошее покрытие кода и проверенные требования важны.

Если вы хотите пойти по пути статической типизации на JVM (у меня есть), я настоятельно рекомендую посмотреть Scala .Исходя из Ruby, это гораздо менее болезненно (и на самом деле очень весело по-разному), чем переход на Java.Вы можете «сохранить» то, что вы считаете само собой разумеющимся - синтаксис на основе выражений, замыкания, возможность пропустить типы во многих местах (не такие открытые, как Ruby, но вы получаете проверку типов во время компиляции ;-),Все (*) - объектно-ориентированная ОО, унифицированные методы доступа, возможность легко создавать DSL и сахар - и получить преимущества статически типизированного языка с локальным выводом типа, сопоставлением с шаблоном, относительно богатой структурой сбора идостойная интеграция с Java (включая многочисленные веб-фреймворки, есть также некоторые специфичные для Scala фреймворки, использующие язык Scala).

C # 3.0 / 4.0 (и .NET3.5 +) не слишком потрепанный либо (но избегайте C # 2.0, который теперь, надеюсь, является реликвией), с введением LINQ / замыканий, базового вывода типов и других приятных языковых функций, которые я считаю "приемлемыми" для большинства задач (угадать, как бы я оценил Java как язык ;-).Тем не менее, C # является CLR-целевым языком (есть / был порт .NET Scala, но я не уверен в его статусе - он не является основной целевой платформой).

Поскольку я упомянул Scala, я должен также упомянуть F # (теперь «официальный» язык .NET), который использует подход «Функциональный с OO», аналогичный OCaml - Scala - это скорее наоборот, и яописал бы это как "ОО с Функциональным".Я слышал аргументы за / против F # по сравнению с C # относительно системы типов, но у меня нет практического опыта работы с F #.Вам может или не может понравиться сдвиг парадигмы.

Счастливое кодирование.

Answer 2

Поскольку вы упоминаете Rails и, если вы заинтересовались Scala, вам обязательно нужно проверить Lift . Вот 2008 интервью с его создателем и 2009 презентация (видео), которые я связываю, потому что, хотя и старые, они сравнивают Lift с альтернативами на других языках.

Если Lift - не ваша вещь, будьте уверены, что есть другие веб-фреймворки Scala .

Answer 3

Этот тип тестирования обычно не выполняется в Rails. Вместо того, чтобы раздражаться от необходимости делать это, не беспокойтесь об этом. Или, возможно, лучше объяснить, почему вы считаете это проблемой, поскольку большинство программистов на Rails этого не делают.

Обновление

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

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

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