Примечание для читателей : потерпите меня.Я обещаю, что есть вопрос.
Мне нужно решить проблему и подумать про себя: «О, я сделаю это в 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 "brian@troutwine.us"]?
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 и не имеет возможности продолжить проект с тестами с разделенными файлами. - Всеэто должно быть написано или скопировано вручную для каждого нового проекта.
Проверка реального мира Haskell Chapter 11 вы обнаружите, что он даже не упоминает междусобойчик и юбки вопрос о макете проекта полностью.Ни один из ресурсов, на которые Дон Стюарт любезно отвечает с здесь , не упоминается ни в одном из вышеупомянутых, и, отмечу, г-н Стюарт не объясняет , как использовать какой-либо изинструменты, на которые ссылаются.
Обратите внимание, что принятый ответ в Рабочий процесс тестирования Haskell ссылается на проект, который с тех пор продвигается достаточно, чтобы не быть хорошим ответом, но действительно говорит
Поскольку тест для каббалы еще не существует - у нас есть студент, работающий над ним для летнего кода этого года!- лучший механизм, который у нас есть, это использовать механизм пользовательского захвата cabal.
Эй, хорошо, документация клики!В соответствующем разделе есть примеры, но они ужасно надуманы, но не создают впечатления, что каждый сам по себе и удачи вам.
Конечно, естьвсегда test-framework , что выглядит неплохо, но пример кода не предлагает ничего, кроме того, что видно в вики, и не масштабируется в том смысле, что как только моя программа усложняется, яна крючке, чтобы разработать способы разделения тестов на управляемые модули.Я даже не уверен, что происходит с HTF и согласен с Мистер.Волков оценка.
Мистер.Комментарий Джелвиса 'по связанному вопросу HTF представлял для меня особый интерес: цепь инструментов Haskell очень сильно страдает от тирании небольших решений.На самом деле я не могу приступить к выполнению поставленной задачи - решить мою проблему в Хаскеле - потому что я нахожусь на крючке для того, чтобы получить правильное окружение просто .Почему это плохо:
- Это напрасная трата усилий.Если я не напишу тестовый инструмент, меня очень, очень редко будет волновать, как мои тесты отстают, только с , где .
- Трудно учиться.Кажется, что нет единственного ресурса для создания проекта с запеченным тестированием, и различные источники, которые существуют, достаточно разнообразны, чтобы быть бесполезными.
- Трудно воспроизвести.С таким количеством движущихся частей, которые я могу организовать, я каждый раз буду делать это по-разному.
- Как следствие, это своеобразно.Это означает, что трудно сотрудничать и подбирать неактивные проекты.
Это просто воняет.
Может быть, я ошибаюсь.Существует ли какой-то плохо рекламируемый инструмент или тщательно разработанные инструменты для создания чего-то похожего на Bundler + Rspec в пространстве Haskell?Если нет, то есть ли плохо рекламируемый канонический пример современного тестирования на Haskell со всеми выпеченными на вкус г-ном Стюартом?Созданный или продемонстрированный проект:
- должен по соглашению и инструментам четко определять код тестирования отдельно от кода приложения (в Ruby-land тесты Rspec выполняются в
spec/, функции огурца вfeatures/), - не должно требовать от конечных пользователей компиляции и установки тестовых зависимостей
- должно быть легко воспроизводимым, желательно не более чем за 10 минут и
- должно бытьстандартизированы или есть надежда на стандартизацию.
Неужели я ошибаюсь, полагая, что в Хаскел-ланде нет ничего подобного?
Edit0: Обратите внимание, RubyСообщество языка не единственное применимое сравнение.Пол Р. прав в определении сильного течения конфигурации над соглашением.Другие языки решают проблему получения масштабируемой структуры проекта с нуля другими способами:
- C :: Этот язык почитаем и настолько хорошо задокументирован, что у вас возникнут проблемы с выяснением, какойдокументированный подход, чтобы принять.Никаких инструментов как таковых.
- Java :: Конфигурация поверх соглашения: вы связаны с этим на уровне компилятора.Много инструментов и очень хорошо документированы.
- Scala :: Сильная поддержка инструментов.
- Erlang :: Достоверно и свободно документировано, если вы знаете, что ищете.Возможно, конфигурация выше соглашения, если вы используете rebar или иным образом ориентируетесь на OTP.
Решение Пола Р. использовать пользовательский шаблон прекрасно работает, если, например, C,есть достаточно документации, чтобы собрать такую вещь.Это все еще сталкивается с проблемами, которые я попытался явно идентифицировать в посте, но это выполнимо.Лучшее предложение на Haskell, о котором я знаю, - это «Как написать программу на Haskell», но это не то же самое, что сбросить одинокого новичка в лесу с фонариком и флягой с водой.
Кроме того, да, статические типы великолепны и решают многие проблемы, которые в противном случае потребовали бы явного тестирования.Если бы они были конечным решением или, в большинстве случаев, достаточным, даже snap-framework не был бы так тщательно протестирован.(Возможно, «Copy snap-core.» - ответ на мой вопрос.)