Como fazer o Test Driven Development (TDD) no Drupal?

• Quais são as ferramentas utilizadas no TDD no Drupal (módulos PHP, módulos Drupal, etc)?
• Como é o seu fluxo de trabalho de confirmação / teste / implantação? Você usa Phing, PHPUnderControl, Hudson para gerenciar esse fluxo de trabalho?
• De que maneira o teste de unidade torna seu código mais confiável?
• Você precisa de um servidor de teste de unidade separado, caro e autônomo, ou pode fazê-lo em um laptop?

Eu sei que Robert escreveu um excelente post técnico aqui sobre testes de unidade no Drupal com o SimpleTest; Estou mais interessado em cobrir o fluxo de trabalho e a parte de configuração. Atualmente, tenho uma máquina de desenvolvimento, preparo e servidor de produção. Os sites de produção e de estágio são executados em um CPU Dreamhost VPS de 300 MB de RAM / 300 MHz.

No mundo do rubi, o TDD é facilitado por ferramentas incorporadas na estrutura. O Factory Girl, o Mocha, o rSpec e outros permitem que os desenvolvedores criem testes de maneira fácil e dinâmica que atendam aos casos de teste necessários.

Também fiquei frustrado com a falta de ferramentas TDD no Drupal. Meu maior problema com eles é a quantidade de tempo que leva para executar um único teste. Os ciclos de desenvolvimento não podem ser mais lentos por testes individuais, levando de 60 a 90 segundos a cada iteração. Os conjuntos de testes completos seriam executados no período de várias horas, se você se importasse em escrever os testes.

Eu suspeito que isso esteja relacionado à cópia de um banco de dados completo toda vez que um teste for executado, mas isso provavelmente não mudará no futuro próximo do que posso dizer, especialmente se você precisar usar o DrupalWebTestCase para fazer isso.

Estou criando uma solução usando Phactory e phpunit, que inicializam o Drupal manualmente. Obviamente, encontrei alguns problemas e ainda não o terminei, mas está chegando lá.

Felizmente, a maior parte do meu trabalho está na camada de back-end, para que eu possa permanecer no nível DRUPAL_BOOTSTRAP_DATABASE. Mas estou correndo para mais situações em que precisarei da pilha completa.

No final, o TDD no Drupal não é bem suportado; portanto, você pode escrever o seu próprio para fazê-lo funcionar fora da estrutura de teste do drupal ou suportar o baixo desempenho.

- ATUALIZAÇÃO -

Eu configurei com sucesso uma integração completa do Drupal com o Phactory e agora estou executando meus testes via phpunit em vez do Drupal Web Test Case. Então é possível.

Espero chegar a um ponto em que posso liberá-lo e ele pode ser incorporado ao documento Phactory.

- ATUALIZAÇÃO 2 -

Doc sobre como eu configuro o Phactory está em https://github.com/trimbletodd/phactory .

Como o blog de Mark está offline, mencionarei algumas das ferramentas que sua equipe implementou:

Teste funcional: Selênio
Teste de unidade:
Servidor de compilação mais
simples : Jenkins Benchmarking de desempenho: XDebug + Cachegrind

Nos dois anos desde que fiz essa pergunta, vi algumas ferramentas adicionais ganharem popularidade no cenário TDD. Hoje em dia, quando você fala em Desenvolvimento Orientado a Testes (em um contexto Drupal, é claro), existem dois lados da mesma moeda - testes de front-end e back-end.

Aqui estão duas apresentações que se destacam da mais recente Drupalcon Portland 2013, representando este assunto:

Desenvolvimento, pelos números , teste de back-end.
Teste automatizado com Jasmine e PhantomJS , teste de front- end.

A primeira apresentação não está relacionada a testes unitários ou funcionais (a rigor), trata-se de ferramentas para medir a qualidade do código. No entanto, sinto que está um pouco relacionado ao tópico.

A única coisa que sei é que, para os módulos contribuídos, você pode ativar o teste automatizado de confirmações e correções na fila de problemas, consulte http://drupal.org/node/689990 . Ainda é um pouco instável, especialmente se você tiver dependências.

A maioria dos projetos provavelmente está mais desenvolvendo algo semelhante ao desenvolvimento orientado a erros, que basicamente se resume a escrever um teste primeiro quando um erro foi encontrado e depois corrigi-lo. Se houver;)

Pela minha experiência pessoal, o TDD é bastante difícil no Drupal, porque geralmente você não escreve (apenas) testes de unidade com o Simpletest, mas testes de integração, onde você visualiza páginas e envia formulários. Portanto, pode ser bastante difícil escrever bons testes com antecedência. Mas talvez eu não esteja acostumado a fazer isso :)