A resposta curta é Leia a entrada Fine Manual sobre testes de banco de dados no manual PHPUnit .
E agora a resposta longa...
A primeira coisa a lembrar sobre o teste de unidade é que ele precisa ser realizado em isolamento de todos os outros componentes. Muitas vezes, esse objetivo é simplificado usando técnicas de inversão de controle (IoC), como injeção de dependência . Quando suas classes solicitam explicitamente suas dependências nos métodos do construtor, é uma operação simples simular essas dependências para que você possa testar o código restante isoladamente.
Testar o código que interage com os modelos é um pouco diferente. Normalmente não é prático ou aconselhável injetar seus modelos na classe em que você precisa acessá-los. Seus modelos geralmente são estruturas de dados "burras" que expõem recursos limitados ou inexistentes. Como resultado, é geralmente aceitável (em termos de testabilidade) instanciar seus modelos em tempo real dentro de suas classes injetadas. Infelizmente, isso dificulta o teste do código do banco de dados porque, como observa a documentação do PHPUnit:
Então, como você isola e testa o código que interage com o banco de dados se os modelos não forem injetados diretamente? A maneira mais simples de fazer isso é utilizar test fixtures .
Como você definitivamente já está usando o
PDO ou uma biblioteca ORM que se baseia em PDO (certo?), configurar os fixtures é tão simples quanto semear um banco de dados SQLite básico ou arquivo XML com dados para acomodar seus casos de teste e usar essa conexão de banco de dados especial quando você testa o código que interage com o banco de dados. Você pode especificar essa conexão em seu arquivo de inicialização do PHPUnit, mas provavelmente é mais semanticamente apropriado configurar um Caso de teste do banco de dados PHPnit
. As etapas de práticas recomendadas geralmente aceitas para testar o código do banco de dados (elas também são ecoadas na documentação do PHPUnit sobre testes de banco de dados):
- Configurar o acessório
- Sistema de exercícios em teste
- Verificar resultado
- Desmontagem
Então, para resumir, tudo o que você precisa fazer é criar um acessório de banco de dados "fictício" e fazer com que seu código interaja com esses dados conhecidos em vez de um banco de dados real que você usaria na produção. Este método permite isolar com sucesso o código em teste porque ele lida com dados conhecidos, e isso significa que você pode fazer declarações específicas/testáveis sobre os resultados de suas operações de banco de dados.
ATUALIZAÇÃO
Só porque é um guia extraordinariamente útil para o que não fazer em seu código se você quiser promover a testabilidade, estou adicionando um link para Como escrever código 3v1L não testável . Não está envolvido com testes de banco de dados em particular, mas é útil mesmo assim. Feliz teste!
ATUALIZAÇÃO 2
Eu queria responder ao comentário sobre adiar o teste de modelo porque a base de código existente não implementa o
PDO para acesso ao banco de dados:Seus modelos não precisam usar PDO para implementar a extensão DbUnit do PHPUnit.
Vai tornar a sua vida um pouco mais fácil se você usar o PDO, mas você não é obrigado a fazê-lo. Digamos, por exemplo, que você criou seu aplicativo com o
pg_* integrado do PHP Funções do PostgreSQL. O PHPUnit ainda permite que você especifique fixtures e ainda pode reconstruí-los para cada teste -- você simplesmente precisaria apontar sua conexão ao realizar testes para o mesmo recurso que a extensão DbUnit usa para seu fixture. 
