Подтвердить что ты не робот

Существует ли какой-либо эквивалент Haskell-land для Ruby-land Bundler et. al, а если нет, то каким образом был бы разработан проект так структурирован?

Примечание для читателей: Потерпите меня. Я обещаю там вопрос.

У меня есть проблема, чтобы решить и подумать: "О, я сделаю это в Ruby".

$ bundle gem problemsolver
      create  problemsolver/Gemfile
      create  problemsolver/Rakefile
      create  problemsolver/.gitignore
      create  problemsolver/problemsolver.gemspec
      create  problemsolver/lib/problemsolver.rb
      create  problemsolver/lib/problemsolver/version.rb
Initializating git repo in /tmp/harang/problemsolver

Снимите комментарий s.add_development_dependency "rspec" в problemsolver/problemsolver.gemspec, а затем

$ bundle exec rspec --init
The --configure option no longer needs any arguments, so true was ignored.
  create   spec/spec_helper.rb
  create   .rspec

Новые тесты идут в spec/ и должны быть в файлах, заканчивающихся на _spec.rb. Например, spec/version_spec.rb

describe 'Problemsolver' do
  it 'should be at version 0.0.1' do
    Problemsolver::VERSION.should == '0.0.1'
  end
end

Для запуска спецификаций - игнорирующих бегунов смены кода, таких как guard - тривиально:

$ bundle exec rspec
.

Finished in 0.00021 seconds
1 example, 0 failures

Вы не можете видеть это, но сообщение красиво закодировано для быстрого "Я испортил?" сканирование? То, что очень хорошо об этом:

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

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

Это неблагоприятно отличается от ситуации, если вы думаете: "О, я сделаю это в Хаскелле".

$ mkdir problemsolver

$ cd problemsolver/

$ cabal init
Package name [default "problemsolver"]? 
Package version [default "0.1"]? 0.0.1
Please choose a license:
   1) GPL
   2) GPL-2
   3) GPL-3
   4) LGPL
   5) LGPL-2.1
   6) LGPL-3
 * 7) BSD3
   8) MIT
   9) PublicDomain
  10) AllRightsReserved
  11) OtherLicense
  12) Other (specify)
Your choice [default "BSD3"]? 
Author name? Brian L. Troutwine
Maintainer email [default "[email protected]"]? 
Project homepage/repo URL? 
Project synopsis? Solves a problem.
Project category:
   1) Codec
   2) Concurrency
   3) Control
   4) Data
   5) Database
   6) Development
   7) Distribution
   8) Game
   9) Graphics
  10) Language
  11) Math
  12) Network
  13) Sound
  14) System
  15) Testing
  16) Text
  17) Web
  18) Other (specify)
Your choice? ProblemSolver
ProblemSolver is not a valid choice.
Your choice? 18
Please specify? ProblemSolver
What does the package build:
   1) Library
   2) Executable
Your choice? 2
Generating LICENSE...
Generating Setup.hs...
Generating y.cabal...

You may want to edit the .cabal file and add a Description field.

"Отлично, - думаешь ты, - я был так обеспокоен. Я уверен, что все последние лучшие практики Haskell в разработке программного обеспечения просто ждут моего диска".

$ ls
LICENSE  problemsolver.cabal  Setup.hs

Позвольте мне обобщить мои чувства: :(

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

  • Все исходные коды Haq попадают в корневой каталог.
  • Тестовый код для Haq находится только в Test.hs, это только QuickCheck и не имеет возможности для продолжения проекта с помощью тестов с разделенным файлом.
  • Все это должно быть вручную записано или скопировано для каждого нового проекта.

Проверка Real World Haskell Глава 11, вы обнаружите, что он даже не упоминает о том, что каббала и юбки не затрагивают вопрос о макете проекта. Ни один из ресурсов, которые Дон Стюарт любезно отвечает здесь, рассматривается в любом из вышеупомянутых и, я хочу заметить, г-н Стюарт не объясняет, как использовать любые ссылок на инструменты.

Обратите внимание, что принятый ответ в рабочем процессе тестирования Haskell ссылается на проект, так как он перемещен достаточно, чтобы не быть хорошим ответом, но говорит

Так как тест каббала еще не существует - у нас есть студент, который работает над этим летом лета кода! - лучший механизм, который у нас есть, - использовать механизм крюка пользователя cabal.

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

Конечно, всегда test-framework, который кажется приятным, но код примера не предлагает ничего, кроме того, что видно в wiki и не масштабируется в том смысле, что, как только моя программа будет усложняться, я нахожусь на пути к разработке способов деления тестов на управляемые модули. Я даже не уверен, что происходит с HTF и согласен с Mr. Волкова оценка.

Г-н. Jelvis ", связанный с вопросом о HTF, представлял для меня особый интерес: инструментальная цепочка Haskell страдает, очень плохо, от тирании небольших решений. Я не могу на самом деле перейти к задаче - решить мою проблему в Haskell - потому что я нахожусь на крючке для того, чтобы моя среда была в порядке. Почему это плохо:

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

Это просто воняет.

Возможно, я ошибаюсь. Существует ли какой-либо плохо рекламируемый инструмент или тесно разработанные инструменты, чтобы сделать что-то подобное Bundler + Rspec в пространстве Haskell? Если нет, есть ли плохо рекламируемый канонический пример современного теста Haskell со всем мистером Стюартом, на который ссылаются лакомства, испеченные прямо? Проект был создан или продемонстрирован:

  • по соглашению и инструменту четко определить код проверки отдельно от кода приложения (в Ruby-land, тесты Rspec идут в spec/, функции Cucumber в features/),
  • не требует от конечных пользователей компиляции и установки тестовых зависимостей
  • должен быть легко воспроизводимым, желательно не более 10 минут и
  • следует стандартизировать или надеяться на стандартизацию.

Неужели я ошибаюсь, полагая, что в Haskell-land нет ничего подобного?

Edit0: Обратите внимание, что языковое сообщество Ruby не является единственным применимым сравнением. Пол Р. правильно идентифицирует сильный ток конфигурации по соглашению. Другие языки решают проблему получения масштабируемой структуры проекта с земли другими способами:

  • C:: Этот язык почтенный и настолько хорошо документированный, что вам будет трудно понять, какой хорошо документированный подход принять. Никакой инструмент как таковой.
  • Java:: Конфигурация по соглашению: вы связаны с ним на уровне компилятора. Многие инструменты и очень хорошо документированы.
  • Scala:: Сильная поддержка инструмента.
  • Erlang:: Достопочтенный и свободно документированный, если вы знаете, что ищете. Возможно, конфигурация по соглашению, если вы используете rebar или иначе ориентированы на OTP.

Решение Paul R. с использованием настраиваемого шаблона отлично работает, если, например, C, имеется достаточная документация для компиляции такой вещи. Это все еще сталкивается с проблемами, которые я попытался явно идентифицировать в сообщении, но он работает. Лучшее предложение Haskell, о котором я знаю, - это "Как написать программу Haskell", но это не значит, что это больше, чем эквивалент сброса одинокого разведчика-куба в лесу с фонариком и флягой с водой.

Кроме того, да, статические типы велики и решают многие проблемы, которые в противном случае нуждались бы в явном тестировании. Если бы они были окончательным решением, или в основном достаточным, даже, snap-framework не были бы столь тщательно протестированы. (Возможно, "Скопировать привязку".) Ответ на мой вопрос.)

4b9b3361

ОТВЕТЫ

Ответ 1

В настоящее время нет ни одного способа настроить testuite. Надеемся, что люди будут стандартизироваться на cabal test, который является готовым. Фактически, как HUnit, так и QuickCheck также предоставляются платформой Haskell, поэтому для настройки тестов не требуется загрузка каких-либо дополнительных зависимостей.

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

TL;DR; Используйте cabal test. Я увлекаюсь test-framework, с которым вы можете интегрироваться с cabal test, если хотите. Извините, что cabal test является своего рода новым, и не все ресурсы, которые у нас есть (обычно редактируемые сообществом), были обновлены, чтобы указать на него и описать, как его использовать. Обновление большого количества ресурсов и создание учебных пособий - это работа сообщества. Мы должны, вероятно, сделать лучшую работу, продвигая множество новых потрясающих инструментов, внедренных в экосистему Haskell за последние несколько лет.

Ответ 2

Здесь много пунктов. Во-первых, существует сравнение условной конфигурации с явной конфигурацией. На рубинской земле часто предпочитают бывшие. По моему опыту, хотя он отлично работает для do-a- {blog | social-thing | gem | library} -in-5-minutes-screencast и быстрых экспериментов, он имеет гораздо меньшую ценность в ваших реальных проектах (более 5 минут), поскольку время инициализации быстро амортизируется. Кроме того, есть причина, по которой инструменты предоставляют средства настройки: существует множество различных потребностей и обычаев. Поэтому мой совет для вашей проблемы с cabal-init: создать собственный файл шаблонов. Положите заглушку на все, что вам нужно, с замечаниями и используйте ее, когда вам это нужно.

Что касается тестов, пейзаж отличается от рубина и haskell. В рубине можно написать foo do { oh dear I am typing nonsense here }, и нет другого способа поймать эту глупость, чем фактически запустить код. Поэтому автоматические тесты абсолютно необходимы. Тем не менее, на земле хекелл есть большой статический анализ вашего кода в сочетании с очень здравомыслящей парадигмой (чисто функциональной нестрогой), и после многих лет ее использования я все еще удивляюсь, что писать бессмысленно без необходимости немедленно пойманный компилятором. Я тоже работаю на рубине, и действительно, 90% моих тестов - это "статические проверки" для малоимущих.

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

Итак, мой вывод здесь: не удивляйтесь, чтобы найти тень везде, если вы затушевываете рубиновый свет на земле хеккеля. Здесь все по-другому, и нужно быть опытным, чтобы захватить власть. Это не означает, что все идеально, на самом деле улучшение инструментальной цепочки - это часто выраженное желание. Только то, что вы подняли, не очень проблематично и действительно не заслуживает того, что вы выбрали. Попробуйте сначала, судите после:)