> Vou falar um "pouco" sobre o que eu sei, mas eu recomendo que todos
> procurem na internet e estudem, pois o assunto é interessante.

> A primeira vantagem de se escrever teste é trivial. Ao invés de ficar
> fazendo testes manualmente, você escreve programas que testam
> automaticamente. Testes automatizados criam uma malha protetora, garantindo
> que seu código faça aquilo que você pensa que ele tem que fazer. Automatizar
> testes ajudam você testar aquela  aplicação de 5000 linhas em pequeno tempo
> de execução.

> Bem, como esta técnica notoriamente é vantajosa, os desenvolvedores
> começaram a usa-la e uns malucos acharam TÃO boa que começaram a testar
> antes mesmo de escrever código. Dai nasce o TDD[1]. Você não pode testar
> manualmente alguma coisa que ainda não criou, mas pode programar algo que
> teste.

> Como os programadores buscam sempre o DRY (dont repeat yourself), foram
> criados vários frameworks e ferramentas para melhorar a forma com que
> testamos, posso citar os xUnits, a cobertura de testes, gerenciadores de
> macros, fixtures, etc. São inúmeras ferramentas e, normalmente, cada
> linguagem possui um grande conjunto delas, portanto não vou me aprofundar
> nisto.

> No CakePHP, o framework de teste utilizado é o SimpleTest[2]. A função de
> um framework de teste é prover o cenário ideal para se realizar testes. Quem
> mexe com experimentos sabe a importância de se ter um ambiente apropriado.
> Um exemplo desta preparação de ambientes são os fixtures. Para fazermos
> testes é importante sabermos o estado inicial de sua aplicação. Imagine
> testar a inserção de um comentário em um tópico, no momento de
> desenvolvimento do teste, você tinha certeza que o tópico existia, mas se no
> momento de execução do teste ele não existir? Seu teste irá falhar, mas não
> por que seu programa está corrompido, mas sim por que o estado inicial do
> teste não estava controlado.

> Os principais métodos que usamos no framework são os métodos de Assert, no
> SimpleTest encontramos diversos[3], eles nos auxiliam a testar vários tipos
> de situações. É fazendo asserções que vocês irão testar seus códigos. Um
> exemplo de asserção é: Se eu passar o valor 5 para uma função de fatorial o
> resultado tem que ser 120. As asserções são feitas na tentativa de explorar
> seus códigos. Não é interessante fazer 10 asserções testando todos os
> valores entrado entre 5 e 15. Mas se eu testar alguns valores chaves, que
> realmente tragam significado, estarei realmente protegendo minha aplicação.
> No exemplo, alguns testes interessantes são valores negativos, 0 e 1.

> Os testes são divididos em 3 grandes áreas (me desculpem se estou falando
> alguma merda): Unitário, Funcional e de Aceitação. Os de aceitação são
> aqueles que envolve testes que o seu cliente faria, testes que envolvem a
> interface, algo que pegue a aplicação inteira. Mesmo existindo ferramentas
> para estes testes, normalmente não se roda toda hora, eles podem ser
> custosos. Testes funcionais são aqueles que testam integrações entre objetos
> e métodos, é quando dois ou mais objetos devem trabalhar juntos. Já os
> testes unitários testam a lógica local de um objeto, de um método. Não tem
> muita diferença entre unitário e funcional, somente o conceito.

> Bem, é este o conceito por trás dos testes, não sei mais o que eu posso
> falar. Para dar algo prático, vou tentar falar um pouco de como testar no
> CakePHP, mas não prometo muita coisa, não tem como falar de tudo.

> A primeira coisa que vocês terão que fazer é colocar o SimpleTest na pasta
> Vendors (seja ela da aplicação ou do cake), assim vocês poderão rodar os
> testes. A título de experiência, visitem o link
> http://endereco_aplicacao/test.php . É nesta página que vocês irão
> executar os seus testes. O CakePHP deixa que você execute os testes do Core
> (coisa que acredito que não precisava, mas acho que eles deixaram para
> estimular o pessoal a contribuir com o desenvolvimento). Rodem algum teste
> (recomento o Views, pois não usa banco de dados). Vocês vão encontrar ou uma
> barra verde ou uma barra vermelha com os erros que ocorreram. Quando ocorre
> alguma exceção, algum warning, erro, o que seja, também aparecerá lá.

> Agora que sabem como executar os testes, vamos fazer alguns testes.
> Primeiramente, como tudo no CakePHP, existe uma convenção de nomes de
> arquivos O padrão do Cake é XXXX.test.php. O XXXX pode ser qualquer coisa,
> mas é recomendável que seja o nome do arquivo que você quer testar (quando
> forem fazer cobertura de teste vocês entenderão). Utilizem as pastas
> predefinidas do CakePHP.

> Eu vou utilizar um exemplo aqui sobre um Model de Tópicos, vocês utilizem o
> que for necessário para sua aplicação. Primeira coisa, vou criar um arquivo
> chamado topico.test.php na pasta /app/tests/cases/models. E, utilizarei a
> seguinte estrutura:

> App::import('Model','Topico');
> class TopicoTestCase extends CakeTestCase {
> var $fixtures = array ('topico');

> }

> *Antes de mais nada, eu não utilizo o método que tinha no CookBook do
> Cake. Eu faço diferente e parece que outras pessoas[4] também não gostaram e
> já incluiram uma correção no Cake. Como não sei se esta correção está no RC2
> ou só no SVN, vou explicar o que é necessário para fazer do meu modo. Peço
> desculpas, mas não vou explicar o por que disto, pois só iria complicar,
> mais explicações no [4].

> Adicionem no app_model.php de sua aplicação a seguinte lógica: *

> function __construct(){

> if(isset($_GET['app'])){
> $this->useDbConfig = 'test'; // Ou nome do seu DataSource de teste (aquele
> que fica no arquivo database.php)
> }
> parent::__construct();
> }

> Agora voltando, o código inicial é simples, primeiro estamos incluindo a
> classe Topico para podermos instancia-la e testa-la. Criamos uma sub-classe
> de Case do CakeTestCase, assim teremos todo o ambiente necessário para
> podermos testar. E colocamos uma variável chamada fixtures. PARA! O que é
> fixtures?

> Bem, lembram quando falei de ambiente de testes? de que tínhamos de ter
> controle do estado inicial de nossos testes? Quem garante isto são os
> Fixtures. O fixture vai, A CADA teste LIMPAR todo o banco e REPOPULAR com as
> ENTRADAS especificadas no arquivo de fixtures. Assim, você terá a certeza de
> que todo inicio de teste você tem um banco limpinho e bunitinho. No meu
> exemplo, o arquivo teria o nome topico_fixture.php e ficaria no
> /app/tests/fixtures/ :

> class TopicoFixture extends CakeTestFixture {
> var $name   = 'Topico';
> var $fields = array(
> 'id' => array(
> 'type' => 'integer',
> 'key'  => 'primary'
> ),
> 'titulo' => array(
> 'type'   => 'string',
> 'length' => 200,
> ),
> 'publicado'=> array(
> 'type'   => 'boolean'
> )
> );
> var $records = array(
> array(
> 'id'=>1,
> 'titulo'=>'Como escrever um e-mail gigantesco',
> 'publicado'=>true
> ),
> array(
> 'id'=>2,
> 'titulo'=>'Como ler um texto antes de escrever?',
> 'publicado'=>false
> )
> );
> }

> Só para explicar, a variável $fields é a estrutura do banco (vocês podem
> utiliza o shell schema para gerar isto para vocês[5]) e o $records são os
> dados que ele irá incluir. (olhem o CookBook, tem mais coisa [6])

> Agora é só fazermos os testes. Para fazermos nossos testes, vamos usar a
> convenção de nome de função do CakePHP. Iniciamos todas as funções que
> queremos que sejam executadas no Case com o seguinte formato testXXXXXX,
> cada função será um teste. Dentro desta função você usa os Asserts. No
> exemplo, vou testar uma funcionalidade do meu model que retorna o número de
> Topicos publicados.

> function testNumeroPublicados(){
> $modelo =& new Topico();
> $esperado = 1;
> $encontrado = $modelo->numeroPublicado();
> $this->assertEqual($esperado,$encontrado);
> }

> Simples não? A lógica do método numeroPublicado() não importa, ele pode até
> mesmo não exitir, o que estamos fazendo aqui é o teste. Uma coisa importante
> de se lembrar é que temos liberdade de "estragar" o banco, pois os fixtures
> vão recompo-lo novamente no próximo teste, exemplo:

> function testNumeroPublicados(){
> $modelo =& new Topico();
> $esperado = 1;
> $encontrado = $modelo->numeroPublicado();
> $this->assertEqual($esperado,$encontrado);
> $modelo->publicarId(2);
> $esperado = 2;
> $encontrado = $modelo->numeroPublicado();
> $this->assertEqual($esperado,$encontrado);
>  }

> Entenderam? Agora é só melhorando os testes, forçando algumas situações,
> algo que possa dar problemas. Bem, escrever teste é como escrever código,
> vocês vão ter que melhorar, refatorar, pensar em novas lógicas, etc.

> Bem pessoal, espero ter ajudado. Com mais calma eu vou melhorar o que
> escrevi aqui. Mas agora eu quero que vocês tentem em casa, no trabalho,
> façam perguntas e o mais importante: testem suas aplicações completamente.

> Abraços.

> [1]http://www.improveit.com.br/xp/praticas/tdd
> [2]http://simpletest.org/
> [3]http://simpletest.org/api/SimpleTest/UnitTester/UnitTestCase.html
> [4]

> Muito bom mesmo, foi o melhor descritivo que já vi sobre testes.
> Acho que seria de grande utilidade que estivesse no site
> cakephp.com.br (Ai bill vai a dica, rs)

> Abraços,

> 2008/9/4 João José Pedrini <joaoj...@usosim.com.br> Hahaha, não sou
> mestre em nada =D

> Vou falar um "pouco" sobre o que eu sei, mas eu recomendo que todos
> procurem na internet e estudem, pois o assunto é interessante.

> A primeira vantagem de se escrever teste é trivial. Ao invés de
> ficar fazendo testes manualmente, você escreve programas que testam
> automaticamente. Testes automatizados criam uma malha protetora,
> garantindo que seu código faça aquilo que você pensa que ele tem
> que fazer. Automatizar testes ajudam você testar aquela  aplicação
> de 5000 linhas em pequeno tempo de execução.

> Bem, como esta técnica notoriamente é vantajosa, os desenvolvedores
> começaram a usa-la e uns malucos acharam TÃO boa que começaram a
> testar antes mesmo de escrever código. Dai nasce o TDD[1]. Você não
> pode testar manualmente alguma coisa que ainda não criou, mas pode
> programar algo que teste.

> Como os programadores buscam sempre o DRY (dont repeat yourself),
> foram criados vários frameworks e ferramentas para melhorar a forma
> com que testamos, posso citar os xUnits, a cobertura de testes,
> gerenciadores de macros, fixtures, etc. São inúmeras ferramentas e,
> normalmente, cada linguagem possui um grande conjunto delas,
> portanto não vou me aprofundar nisto.

> No CakePHP, o framework de teste utilizado é o SimpleTest[2]. A
> função de um framework de teste é prover o cenário ideal para se
> realizar testes. Quem mexe com experimentos sabe a importância de
> se ter um ambiente apropriado. Um exemplo desta preparação de
> ambientes são os fixtures. Para fazermos testes é importante
> sabermos o estado inicial de sua aplicação. Imagine testar a
> inserção de um comentário em um tópico, no momento de
> desenvolvimento do teste, você tinha certeza que o tópico existia,
> mas se no momento de execução do teste ele não existir? Seu teste
> irá falhar, mas não por que seu programa está corrompido, mas sim
> por que o estado inicial do teste não estava controlado.

> Os principais métodos que usamos no framework são os métodos de
> Assert, no SimpleTest encontramos diversos[3], eles nos auxiliam a
> testar vários tipos de situações. É fazendo asserções que vocês
> irão testar seus códigos. Um exemplo de asserção é: Se eu passar o
> valor 5 para uma função de fatorial o resultado tem que ser 120. As
> asserções são feitas na tentativa de explorar seus códigos. Não é
> interessante fazer 10 asserções testando todos os valores entrado
> entre 5 e 15. Mas se eu testar alguns valores chaves, que realmente
> tragam significado, estarei realmente protegendo minha aplicação.
> No exemplo, alguns testes interessantes são valores negativos, 0 e
> 1.

> Os testes são divididos em 3 grandes áreas (me desculpem se estou
> falando alguma merda): Unitário, Funcional e de Aceitação. Os de
> aceitação são aqueles que envolve testes que o seu cliente faria,
> testes que envolvem a interface, algo que pegue a aplicação
> inteira. Mesmo existindo ferramentas para estes testes, normalmente
> não se roda toda hora, eles podem ser custosos. Testes funcionais
> são aqueles que testam integrações entre objetos e métodos, é
> quando dois ou mais objetos devem trabalhar juntos. Já os testes
> unitários testam a lógica local de um objeto, de um método. Não tem
> muita diferença entre unitário e funcional, somente o conceito.

> Bem, é este o conceito por trás dos testes, não sei mais o que eu
> posso falar. Para dar algo prático, vou tentar falar um pouco de
> como testar no CakePHP, mas não prometo muita coisa, não tem como
> falar de tudo.

> A primeira coisa que vocês terão que fazer é colocar o SimpleTest
> na pasta Vendors (seja ela da aplicação ou do cake), assim vocês
> poderão rodar os testes. A título de experiência, visitem o link
> http://endereco_aplicacao/test.php . É nesta página que vocês irão
> executar os seus testes. O CakePHP deixa que você execute os testes
> do Core (coisa que acredito que não precisava, mas acho que eles
> deixaram para estimular o pessoal a contribuir com o
> desenvolvimento). Rodem algum teste (recomento o Views, pois não
> usa banco de dados). Vocês vão encontrar ou uma barra verde ou uma
> barra vermelha com os erros que ocorreram. Quando ocorre alguma
> exceção, algum warning, erro, o que seja, também aparecerá lá.

> Agora que sabem como executar os testes, vamos fazer alguns testes.
> Primeiramente, como tudo no CakePHP, existe uma convenção de nomes
> de arquivos O padrão do Cake é XXXX.test.php. O XXXX pode ser
> qualquer coisa, mas é recomendável que seja o nome do arquivo que
> você quer testar (quando forem fazer cobertura de teste vocês
> entenderão). Utilizem as pastas predefinidas do CakePHP.

> Eu vou utilizar um exemplo aqui sobre um Model de Tópicos, vocês
> utilizem o que for necessário para sua aplicação. Primeira coisa,
> vou criar um arquivo chamado topico.test.php na pasta
> /app/tests/cases/models. E, utilizarei a seguinte estrutura:

> App::import('Model','Topico');
> ~---

> Seria uma honra se vocês divulgassem este conteúdo em seus sites. Quem mais
> estiver interessado também pode divulgar.

> Cesar,

> Acho que já é um começo para se criar a página de FAQ do grupo da língua
> portuguesa.

> A todos,

> Muito obrigado pelos elogios

> Abraços
> --
> João José Carvalho Pedrini