Nota aos leitores: Tenha paciencia comigo. Eu prometo que há uma pergunta.

Eu tenho um problema para resolver e penso comigo mesmo: "Ah, eu vou fazer isso em Ruby.&quo

$ 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

Remova o comentário ems.add_development_dependency "rspec" dentroproblemsolver/problemsolver.gemspec e depoi

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

Novos testes entram emspec/ e deve estar em arquivos que terminam em_spec.rb. Por exemplo,spec/version_spec.rb

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

Para executar especificações - ignorar os corredores de alteração de código comoguard - é trivial:

$ bundle exec rspec
.

Finished in 0.00021 seconds
1 example, 0 failures

Você não pode vê-lo, mas a mensagem é bem codificada por cores para uma rápida "Eu estraguei tudo?" digitalização? As coisas que são muito boas nisso:

configuração foi rápida, quase sem cérebro (embora descobrir quais comandos chamar não seja trivial layout padronizado da árvore de origem reduz o período de familiarização com uma nova base de código, tornando a colaboração mais simples e reduzindo o tempo de pausa ao escolher um projeto que você deixou um pouc dependência excessiva de ferramentas distribui as melhores práticas pela comunidade, aproximadamente na velocidade da criação de novos projeto

Adicionando ferramentas de cobertura, observadores de código, linters, ferramentas de teste de comportamento e outros não são mais difíceis.

Isso contrasta desfavoravelmente com a situação, se alguém pensa: "Ah, farei isso em Haskell"

$ 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.

"Ótimo", você pensa, "fiquei tão chateado que aposto que todas as mais recentes práticas recomendadas da Haskell em desenvolvimento de software estão apenas esperando no meu disco"

$ ls
LICENSE  problemsolver.cabal  Setup.hs

Permitam-me resumir meus sentimentos::(

O arquivo cabal gerado nem tem umMain especificado, muito menos instruções para configurar um projeto rudimentar. Ainda assim, tudo bem. Se você peidar um pouco tentando encontrar as palavras-chave de pesquisa corretas, encontraráComo escrever um programa Haskell que está bem, exceto:

Todo o código-fonte Haq é lançado no diretório rai O código de teste para Haq é apenas emTest.hs, é apenas o QuickCheck e não possui recursos para continuar o projeto com testes de arquivos dividido Tudo isso deve ser gravado ou copiado manualmente para cada novo projet

Verificando o mundo real de HaskellCapítulo 11 você vai achar que nemmençã cabal e evita completamente a questão do layout do projeto. Nenhum dos recursos que Don Stewart responde gentilmente comaqu são abordados em qualquer um dos itens acima mencionados e, observarei, o Sr. Stewart não explicacom para usar qualquer uma das ferramentas mencionada

Observe que a resposta aceita em Fluxo de trabalho de teste da Haskell faz referência a um projeto que já foi movido o suficiente para não ser uma boa resposta, masfa say

Como o teste cabal ainda não existe - temos um aluno trabalhando nele para o verão de código deste ano! - o melhor mecanismo que temos é usar o mecanismo de gancho do usuário da caba

Hey, ok, a documentação da cabala! O seção apropriada tem exemplos, mas eles são terrivelmente inventados, mas não deixam de dar a impressão de que todos estão sozinhos e boa sorte para voc

Claro, sempre há estrutura de teste isso parece ser bom, mas seu código de exemplo não oferece nada além do que é visto no wiki e não é escalável no sentido de que, assim que meu programa cresce em complexidade, estou à disposição para desenvolver maneiras de dividir testes em módulos gerenciáveis. Eu nem tenho certeza do que está acontecendo com HTF e concorde comSenhor. Volkovvaliação de

Senhor. Jelvis comentário da @ @ sobre a questão HTF vinculada foi de especial interesse para mim: a cadeia de ferramentas Haskell sofre muito com uma tirania de pequenas decisões. Na verdade, não posso me dedicar à tarefa em questão - resolver meu problema em Haskell - porque estou ansioso por obter meu ambientesoment certo. Por que isso é ruim:

É um esforço desperdiçado. A menos que eu esteja escrevendo uma ferramenta de teste, muito raramente me preocuparei com a forma como meus testes são reduzidos, apenas a partir deOnd. É difícil aprender. Parece não haver nenhum recurso singular para a configuração de um projeto com testes prontos, e as várias fontes existentes são suficientemente diversas para serem inútei É difícil de reproduzir. Com tantas peças em movimento para organizar, sou obrigado a fazê-lo de maneira diferente a cada ve Como corolário, é idiossincrático. Isso significa que é difícil colaborar e buscar projetos inativo

Isso simplesmente fede.

Talvez eu esteja errado, no entanto. Existe alguma ferramenta mal anunciada ou ferramentas estreitamente desenvolvidas para fazer algo semelhante ao Bundler + Rspec no espaço Haskell? Se não, existe um exemplo canônico mal anunciado dos testes modernos de Haskell com todos os presentes mencionados por Stewart? O projeto criou ou demonstrou:

por convenção e por ferramentas, mantenha o código de teste separado do código do aplicativo de uma maneira bem definida (em Ruby-land, os testes Rspec são executados emspec/, Pepino apresenta emfeatures/), não deve exigir que os usuários finais compilem e instalem dependências de teste deve ser facilmente reproduzível, desejável em não mais de 10 minutos e deve ser padronizado ou ter a esperança de padronizaçã

Estou errado em acreditar que não há nada assim em Haskell-lan

Edit0: Observe que a comunidade da linguagem Ruby não é a única comparação aplicável. Paul R. está correto ao identificar a forte corrente de configuração ao longo da convenção. Outros idiomas resolvem o problema de obter uma estrutura de projeto escalável de outras maneiras:

C :: Essa linguagem é venerável e tão bem documentada que você terá problemas para descobrir qual abordagem bem documentada deve ser adotada. Nenhuma ferramenta como tal.Java :: Configuração por convenção: você está vinculado a ela no nível do compilador. Muitas ferramentas e muito bem documentadas. Scala :: Forte suporte a ferramentas. Erlang :: Venerável e pouco documentado, se você souber o que está procurando. Provavelmente configuração por convenção, se você estiver usando vergalhão ou de outra forma segmentar o OTP.

solução de @Paul R. de usar um modelo personalizado funciona muito bem se, como C, houver documentação suficiente para compilar isso. Isso ainda tem problemas que tentei identificar explicitamente na postagem, mas é viável. A melhor oferta de Haskell - que eu conheço - é "Como escrever um programa Haskell", mas não chega a ser mais do que o equivalente a jogar um escoteiro solitário na floresta com uma lanterna e um frasco de água.

Além disso, sim, os tipos estáticos são ótimos e resolvem muitos problemas que, de outra forma, precisariam de testes explícitos. Se eles fossem uma solução completa, ou na maior parte suficiente, até, o snap-framework não seria tão completamente testado. (Provavelmente "Copiar snap-core". É uma resposta para minha pergunta.)