Permalink
Browse files

Merge pull request #2228 from alanwillms/add-missing-brazilian-portug…

…uese-translations-to-yii-definitive-guide

Add some missing Brazilian Portuguese translations to Yii Definitive Guide
  • Loading branch information...
2 parents 180347a + d8d5ad6 commit dc6aae584a195b6eacbf817677fd94d5c93f4e36 @samdark samdark committed Mar 20, 2013
View
265 docs/guide/pt_br/extension.create.txt
@@ -0,0 +1,265 @@
+Criando Extensões
+===================
+
+Uma vez que uma extensão visa ser utilizada por outros desenvolvedores, ela
+requer alguns esforços adicionais para ser criada. Estas são apenas algumas
+orientações gerais:
+
+* Uma extensão deve ser auto-contida. Ou seja, sua dependência externa deveria
+ ser mínima. Seria uma dor de cabeça para seus usuários se uma extensão
+ exigisse a instalação de pacotes, classes ou arquivos adicionais.
+* Arquivos que pertencem a uma extensão deveriam ser organizados sob o mesmo
+ diretório cujo nome é o nome da extensão.
+* As classes em uma extensão devem ser prefixadas com alguma(s) letra(s) para
+ evitar conflitos de nomenclatura com classes em outras extensões.
+* Uma extensão deve vir com documentação detalhada de instalação e da API.
+ Isso reduziria o tempo e o esforço necessários por outros desenvolvedores
+ quando eles usam a extensão.
+* Uma extensão deve usar uma licença apropriada. Se você deseja que a sua
+ aplicação seja usada tanto por projetos open-source como closed-source, você
+ pode considerar usar licenças tais como BSD, MIT, etc., mas não GPL já que ela
+ requer que seu código derivado também seja open-source.
+
+A seguir, descrevemos como criar uma nova extensão, de acordo com a sua
+categorização conforme descrita na [visão geral](/doc/guide/extension.overview).
+Estas descrições também se aplicam quando você está criando um componente usado
+principalmente em seus próprios projetos.
+
+Componente da Aplicação
+---------------------
+
+Um [componente da aplicação](/doc/guide/basics.application#application-component)
+deveria implementar a interface [IApplicationComponent] ou estender de
+[CApplicationComponent]. O método principal que precisa ser implementado é o
+[IApplicationComponent::init] no qual o componente faz algum trabalho de
+inicialização. Este método é invocado após cada componente ser criado e os
+valores de propriedades iniciais (especificados na
+[configuração da aplicação](/doc/guide/basics.application#application-configuration))
+serem aplicados.
+
+Por padrão, um componente de aplicação é criado e inicializado somente quando
+ele é acessado pela primeira vez durante o tratamento da requisição. Se um
+componente da aplicação precisa ser criado logo após a instância da aplicação
+ser criada, ele deveria exigir que o usuário listasse seu ID na propriedade
+[CApplication::preload].
+
+
+Comportamento
+--------
+
+Para criar um comportamento, deve-se implementar a interface [IBehavior]. Por
+conveniência, o Yii fornece uma classe-mãe [CBehavior] que já implementa essa
+interface e fornece alguns métodos adicionais convenientes. As classes-filha
+na maioria dos casos só precisam implementar os métodos extra que elas pretendem
+tornar disponíveis aos componentes aos quais são anexadas.
+
+Ao desenvolver comportamentos para [CModel] e [CActiveRecord], pode-se também
+estender a [CModelBehavior] e a [CActiveRecordBehavior], respectivamente. Essas
+classes-mãe oferecem recursos adicionais que foram criados especificamente para
+a [CModel] e a [CActiveRecord]. Por exemplo, a classe [CActiveRecordBehavior]
+implementa um grupo de métodos para responder aos eventos do ciclo de vida
+chamados em um objeto ActiveRecord. Desta forma, uma classe-filha pode
+sobrescrever estes métodos para inserir código personalizado que participará
+nos ciclos de vida do AR.
+
+O código a seguir mostra um exemplo de um comportamento de ActiveRecord. Quando
+este comportamento é anexado a um objeto AR e quando o objeto AR está sendo
+salvo chamando o método `save()`, ele automaticamente definirá os atributos
+`data_criacao` e `data_atualizacao` com a timestamp atual.
+
+~~~
+[php]
+class TimestampBehavior extends CActiveRecordBehavior
+{
+ public function beforeSave($event)
+ {
+ if($this->owner->isNewRecord)
+ $this->owner->data_criacao=time();
+ else
+ $this->owner->data_atualizacao=time();
+ }
+}
+~~~
+
+
+Widget
+------
+
+Um [widget](/doc/guide/basics.view#widget) deve estender de [CWidget] ou suas
+classes-filha.
+
+A maneira mais fácil de criar um novo widget é estender um widget existente
+e sobrescrer seus métodos ou alterar o valor padrão de suas propriedades. Por
+exemplo, se você quer usar um estilo CSS mais legal para a [CTabView], você
+poderia configurar a sua propriedade [CTabView::cssFile] ao usar o widget.
+Você também pode estender a [CTabView] como segue de modo que você não precisa
+mais configurar a propriedade ao usar o widget.
+
+~~~
+[php]
+class MyTabView extends CTabView
+{
+ public function init()
+ {
+ if($this->cssFile===null)
+ {
+ $file=dirname(__FILE__).DIRECTORY_SEPARATOR.'tabview.css';
+ $this->cssFile=Yii::app()->getAssetManager()->publish($file);
+ }
+ parent::init();
+ }
+}
+~~~
+
+No exemplo acima, sobrescrevemos o método [CWidget::init] e designamos para
+[CTabView::cssFile] a URL que aponta para o nosso novo estilo CSS padrão, se a
+propriedade não estiver definida. Colocamos o novo arquivo de estilo CSS sob o
+mesmo diretório contendo o arquivo da classe `MyTabView` de modo que eles possam
+ser empacotados como uma extensão. Uma vez que o arquivo de estilo CSS não está
+acessível na Web, precisamos publicá-lo como um asset.
+
+Para criar um novo widget do zero, precisamos implementar principalmente dois
+métodos: [CWidget::init] e [CWidget::run]. O primeiro método é chamado quando
+usamos `$this->beginWidget` para inserir um widget na visão, e o segundo método
+é invocado quando chamamos `$this->endWidget`. Se quisermos capturar e processar
+o conteúdo exibido entre estas duas chamadas de métodos, podemos iniciar o
+[buffer de saída](http://us3.php.net/manual/en/book.outcontrol.php)
+em [CWidget::init] e obter a saída do buffer em [CWidget::run] para posterior
+processamento.
+
+Um widget frequentemente envolve incluir arquivos de CSS, JavaScript ou outros
+recursos na página que usa o widget. Chamamos esses arquivos de *assets*
+(posses, ativos) porque eles permanecem junto com o arquivo da classe do widget
+e geralmente não estão acessíveis aos usuários da Web. Para tornar estes
+arquivos acessíveis, precisamos publicá-los usando o
+[CWebApplication::assetManager], conforme demonstrado no trecho de código acima.
+Além disso, se quiser incluir um arquivo CSS ou JavaScript na página atual,
+precisamos registrá-lo usando o [CClientScript]:
+
+~~~
+[php]
+class MyWidget extends CWidget
+{
+ protected function registerClientScript()
+ {
+ // ...publica o arquivo CSS ou JavaScript aqui...
+ $cs=Yii::app()->clientScript;
+ $cs->registerCssFile($cssFile);
+ $cs->registerScriptFile($jsFile);
+ }
+}
+~~~
+
+Um widget também pode ter os seus próprios arquivos de visão. Se for o caso,
+crie um diretório chamado `views` dentro do diretório que contém o arquivo da
+classe do widget, e coloque todos os arquivos de visão ali. Na classe do widget,
+de modo a renderizar a visão do widget, use `$this->render('ViewName')`, que
+é parecido com o que fazemos num controle.
+
+Ação
+------
+
+Uma [ação](/doc/guide/basics.controller#action) deve herdar de [CAction] ou suas
+classes-filha. O método principal que precisa ser implementado para uma ação é
+o [IAction::run].
+
+Filtro
+------
+Um [filtro](/doc/guide/basics.controller#filter) deve herdar de [CFilter] ou
+suas classes-filha. Os métodos principais que precisam ser implementados para um
+filtro são [CFilter::preFilter] e [CFilter::postFilter]. O primeiro é chamado
+antes da ação ser executada enquanto o outro é invocado depois.
+
+~~~
+[php]
+class MyFilter extends CFilter
+{
+ protected function preFilter($filterChain)
+ {
+ // lógica sendo aplicada antes que a ação seja executada
+ return true; // false se a ação não deveria ser executada
+ }
+
+ protected function postFilter($filterChain)
+ {
+ // lógica sendo aplicada após a ação ser executada
+ }
+}
+~~~
+
+O parâmetro `$filterChain` é do tipo [CFilterChain], que contém informações
+sobre a ação que está sendo filtrada.
+
+
+Controle
+----------
+Um [controle](/doc/guide/basics.controller) distribuído como uma extensão deve
+herdar de [CExtController], ao invés de [CController]. O motivo principal é que
+[CController] assume que os arquivos de visão do controle estão localizados em
+`application.views.ControllerID`, enquanto [CExtController] assume que os
+arquivos de visão estão localizados sob o diretório `views` que é um
+subdiretório do diretório que contém o arquivo da classe do controle. Portanto,
+é mais fácil redistribuir o controle, uma vez que seus arquivos de visão estão
+juntos com o arquivo da classe do controle.
+
+
+Validador
+---------
+Um validador deve herdar de [CValidator] e implementar seu método
+[CValidator::validateAttribute].
+
+~~~
+[php]
+class MyValidator extends CValidator
+{
+ protected function validateAttribute($model,$attribute)
+ {
+ $value=$model->$attribute;
+ if($value has error)
+ $model->addError($attribute,$errorMessage);
+ }
+}
+~~~
+
+Comandos de Console
+---------------
+Um [comando de console](/doc/guide/topics.console) deve herdar de
+[CConsoleCommand] e implementar seu método [CConsoleCommand::run].
+Opcionalmente, podemos sobrescrever [CConsoleCommand::getHelp] para
+disponibilizar alguma informação de ajuda amigável sobre o comando.
+
+~~~
+[php]
+class MyCommand extends CConsoleCommand
+{
+ public function run($args)
+ {
+ // $args dá um array dos argumentos de linha de comando deste comando
+ }
+
+ public function getHelp()
+ {
+ return 'Uso: como usar este comando';
+ }
+}
+~~~
+
+Módulo
+------
+Por favor, consulte a seção sobre
+[módulos](/doc/guide/basics.module#creating-module) sobre como criar um módulo.
+
+Uma regra geral para desenvolver um módulo é que ele deveria ser auto-contido.
+Arquivos de recursos (como CSS, JavaScript, imagens) que são usados por um
+módulo devem ser distribuídos junto com o módulo. E o módulo deve publicá-los de
+modo que eles estejam acessíveis na Web.
+
+
+Componente Genérico
+-----------------
+Desenvolver uma extensão de componente genérico é como escrever uma classe.
+Novamente, o componente também deve ser auto-contido para que ele possa ser
+facilmente usado por outros desenvolvedores.
+
+
+<div class="revision">$Id$</div>
View
98 docs/guide/pt_br/extension.integration.txt
@@ -0,0 +1,98 @@
+Utilizando Bibliotecas de Terceiros
+=========================
+
+O Yii foi projetado cuidadosamente de modo que bibliotecas de terceiros possam
+ser facilmente integradas para estender ainda mais as funcionalidades do Yii.
+Ao utilizar uma biblioteca de terceiros em um projeto, os desenvolvedores
+frequentemente encontram problemas de nomenclatura de classes e inclusão de
+arquivos. Uma vez que todas as classes do Yii são prefixadas com a letra`C`,
+é menos provável que um problema de nomenclatura de classes ocorra; e já que o
+Yii confia no
+[autoload da SPL](http://us3.php.net/manual/en/function.spl-autoload.php)
+para realizar a inclusão de arquivos de classes, ele pode funcionar bem com
+outras bibliotecas se elas usam a mesma funcionalidade de auto-carregamento ou
+o caminho de inclusão do PHP para incluir os arquivos de classes.
+
+
+A seguir usamos um exemplo para ilustrar como utilizar o componente
+[Zend_Search_Lucene](http://www.zendframework.com/manual/en/zend.search.lucene.html)
+do [Zend framework](http://www.zendframework.com) em uma aplicação Yii.
+
+Primeiramente, extraímos o arquivo do Zend Framework em um diretório em
+`protected/vendors`, assumindo que `protected` é o
+[diretório base da aplicação](/doc/guide/basics.application#application-base-directory).
+Verifique se o arquivo `protected/vendors/Zend/Search/Lucene.php` existe.
+
+Então, no começo de um arquivo de uma classe de controle, insira as seguintes
+linhas:
+
+~~~
+[php]
+Yii::import('application.vendors.*');
+require_once('Zend/Search/Lucene.php');
+~~~
+
+O código acima inclui o arquivo de classe `Lucene.php`. Por estarmos usando um
+caminho relativo, precisamos alterar o caminho de inclusão do PHP de modo que o
+arquivo possa ser localizado corretamente. Isso é feito chamando `Yii::import`
+antes de `require_once`.
+
+Uma vez que a configuração acima tenha sido feita, podemos usar a classe
+`Lucene` em uma ação do controle, como a seguir:
+
+~~~
+[php]
+$lucene=new Zend_Search_Lucene($pathOfIndex);
+$hits=$lucene->find(strtolower($keyword));
+~~~
+
+Utilizando Bibliotecas de Terceiros com Namespace
+------------------------------------
+
+Para utilizar uma biblioteca com namespace que segue o
+[PSR-0](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md)
+(tais como o Zend Framework 2 ou o Symfony2) você precisa registrar a sua raiz
+como um alias de caminho.
+
+Como exemplo utilizaremos a [Imagine](https://github.com/avalanche123/Imagine).
+Se incluirmos um diretório `Imagine` em `protected/vendors` estaremos aptos
+a utilizá-la da seguinte forma:
+
+~~~
+[php]
+Yii::setPathOfAlias('Imagine',Yii::getPathOfAlias('application.vendors.Imagine'));
+
+// E então o código padrão do guia da Imagine
+// $imagine = new Imagine\Gd\Imagine();
+// etc.
+~~~
+
+No código acima, o nome do alias que nós definimos deve ser o mesmo que a
+primeira parte do namespace utilizado na biblioteca.
+
+Utilizando o Yii em Sistemas de Terceiros
+------------------------------
+
+O Yii também pode ser utilizado como uma biblioteca auto-contida para suportar o
+desevolvimento e reforçar sistemas de terceiros existentes, tais como o
+WordPress, Joomla, etc. Para fazer isso, inclua o seguinte código no código de
+inicialização do sistema de terceiros:
+
+~~~
+[php]
+require_once('path/to/yii.php');
+Yii::createWebApplication('path/to/config.php');
+~~~
+
+O código acima é muito parecido com o código de inicialização usado por uma
+aplicação Yii típica, exceto por uma coisa: ele não inclui a chamada do método
+`run()` depois de criar a instância da aplicação Web.
+
+Agora você pode utilizar a maioria das funcionalidades oferecidas pelo Yii ao
+desenvolver melhorias em softwares de terceiros. Por exemplo, você pode usar
+`Yii::app()` para acessar a instância da aplicação; nós podemos utilizar as
+funcionalidades de banco de dados tais como DAO e ActiveRecord; podemos utilizar
+a funcionalidade de modelos e validações; e assim por diante.
+
+
+<div class="revision">$Id$</div>
View
6 docs/guide/pt_br/index.txt
@@ -5,9 +5,9 @@ Esse tutorial está disponível sob os [termos da Documentação do Yii](http://
Todos os Direitos Reservados.
-2008-2010 &copy; Yii Software LLC.
+2008-2013 &copy; Yii Software LLC.
Tradução para o Português:
-Wanderson C. Bragança, luiz.uo, davi_alexandre, Ivan Wilhelm, Sidney Lins (slinstj), Rodrigo Coelho (mentel) e Saulo Onze (sauloonze).
+Wanderson C. Bragança, luiz.uo, davi_alexandre, Ivan Wilhelm, Sidney Lins (slinstj), Rodrigo Coelho (mentel), Saulo Onze (sauloonze) e Alan M. Willms Q. (alanwillms).
-<div class="revision">$Id: index.txt 1679 2010-01-07 21:03:36Z qiang.xue $</div>
+<div class="revision">$Id$</div>
View
112 docs/guide/pt_br/test.fixture.txt
@@ -0,0 +1,112 @@
+Definindo Fixtures
+=================
+
+Testes automatizados precisam ser executados muitas vezes. Para nos assegurarmos
+de que o processo de testes é repetível, gostaríamos de rodar os testes em algum
+estado conhecido chamado *fixture*. Por exemplo, para testar a funcionalidade de
+criação de posts em uma aplicação de blog, toda vez que rodarmos os testes, as
+tabelas armazenando os dados relevantes sobre posts (por exemplo, a tabela
+`Post`, a tabela `Comentario`) devem ser restauradas a algum estado fixo. A
+[documentação do PHPUnit](http://www.phpunit.de/manual/current/en/fixtures.html)
+explicou bem a definição de fixtures genéricas. Nesta seção, descrevemos
+principalmente como configurar fixtures de banco de dados, como acabamos de
+descrever no exemplo.
+
+Configurar fixtures de banco de dados talvez seja uma das partes mais demoradas
+ao testar aplicações Web com banco de dados. O Yii introduz o componente de
+aplicação [CDbFixtureManager] para aliviar este problema. Ele basicamente faz
+as seguintes coisas ao rodar um conjunto de testes:
+
+ * Antes que todos os testes rodem, ele reseta a algum estado conhecido todas as
+ tabelas relevantes para os testes.
+ * Antes que um único método de teste rode, ele reseta as tabelas especificadas
+ para algum estado conhecido.
+ * Durante a execução de um método de teste, fornece acesso às linhas dos dados
+ que contribuem com a fixture.
+
+Para utilizar o [CDbFixtureManager], nós o configuramos na
+[configuração da aplicação](/doc/guide/basics.application#application-configuration),
+conforme segue,
+
+~~~
+[php]
+return array(
+ 'components'=>array(
+ 'fixture'=>array(
+ 'class'=>'system.test.CDbFixtureManager',
+ ),
+ ),
+);
+~~~
+
+Então fornecemos dados à fixture no diretório `protected/tests/fixtures`. Este
+diretório pode ser personalizado para apontar para um diferente configurando-se
+a propriedade [CDbFixtureManager::basePath] na configuração da aplicação. Os
+dados da fixture são organizados como uma coleção de arquivos PHP chamados de
+arquivos de fixtures. Cada arquivo de fixture retorna um array representando as
+linhas de dados iniciais para uma tabela em particular. O nome do arquivo é o
+mesmo que o nome da tabela. Segue um exemplo de dados de fixture para a tabela
+`Post`, armazenados em um arquivo chamado `Post.php`:
+
+~~~
+[php]
+<?php
+return array(
+ 'exemplo1'=>array(
+ 'titulo'=>'post de testes 1',
+ 'conteudo'=>'conteúdo do post de testes 1',
+ 'dataCriacao'=>1230952187,
+ 'autorId'=>1,
+ ),
+ 'exemplo2'=>array(
+ 'titulo'=>'post de testes 2',
+ 'conteudo'=>'conteúdo do post de testes 2',
+ 'dataCriacao'=>1230952287,
+ 'autorId'=>1,
+ ),
+);
+~~~
+
+Como podemos perceber, duas linhas de dados são retornadas no exemplo acima.
+Cada linha é representada como um array associativo cujas chaves são nomes de
+colunas e cujos valores são os valores das colunas correspondentes. Além disso,
+cada linha é indexada por uma string (`exemplo1`, `exemplo2`) que é chamada
+de *alias de linha*. Mais tarde, quando escrevermos os scripts de testes,
+podemos convenientemente nos referir a uma linha por seu alias. Descreveremos
+isso em detalhes na próxima seção.
+
+Você pode notar que nós não especificamos os valores da coluna `id` na fixture
+acima. Isso porque a coluna `id` está definida como uma chave primária
+auto-incrementável cujo valor será preenchido quando inserimos novas linhas.
+
+Quando o [CDbFixtureManager] é referenciado pela primeira vez, ele percorrerá
+todos os arquivos de fixture e os usará para resetar as tabelas correspondentes.
+Ele reseta uma tabela truncando a mesma, resetando o valor da sequence da chave
+primária auto-incrementável, e então inserindo na tabela as linhas de dados do
+arquivo de fixture.
+
+Algumas vezes podemos não querer resetar todas as tabelas que têm um arquivo de
+fixture antes de rodarmos um conjunto de testes, porque resetar muitos arquivos
+de fixtures pode demorar bastante tempo. Neste caso, podemos escrever um script
+PHP para fazer o trabalho de inicialização de uma forma personalizada. O script
+deve ser salvo em um arquivo chamado de `init.php` sob o mesmo diretório que
+contém os outros arquivos de fixtures. Quando o [CDbFixtureManager] detecta a
+existência deste script, ele o executará ao invés de resetar todas as tabelas.
+
+Também é possível que nós não gostemos da maneira padrão de resetar uma tabela,
+ou seja, truncá-la e inserir os dados de fixture. Se este for o caso, podemos
+escrever um script de inicialização específico para o arquivo de fixture. O
+script deve ser nomeado com o nome da tabela com o sufixo `.init.php`. Por
+exemplo, o script de inicialização da tabela `Post` seria `Post.init.php`.
+Quando o [CDbFixtureManager] vê este script, ele o executa ao invés de usar o
+jeito padrão de resetar a tabela.
+
+> Tip|Dica: Ter fixtures demais pode aumentar consideravelmente o tempo de
+testes. Por esse motivo, você só deve fornecer arquivos de fixture para as
+tabelas cujo conteúdo pode mudar durante o teste. Tabelas que só servem para
+consulta não mudam, e portanto não precisam de arquivos de fixture.
+
+Nas próximas duas seções, descreveremos como utilizar as fixtures gerenciadas
+pelo [CDbFixtureManager] em testes unitários e funcionais.
+
+<div class="revision">$Id$</div>
View
104 docs/guide/pt_br/test.functional.txt
@@ -0,0 +1,104 @@
+Testes Funcionais
+==================
+
+Antes de ler esta seção, é recomendável que você primeiro leia a
+[documentação do Selenium](http://seleniumhq.org/docs/) e a
+[documentação do PHPUnit](http://www.phpunit.de/wiki/Documentation). Nós
+resumimos a seguir os princípios básicos de escrita de testes funcionais no Yii:
+
+ * Como nos testes unitários, um teste funcional é escrito em termos de uma
+ classe `XyzTest` que estende de [CWebTestCase], onde `Xyz` representa a
+ classe que está sendo testada. Uma vez que
+ `PHPUnit_Extensions_SeleniumTestCase` é a classe-mãe de [CWebTestCase],
+ podemos usar todos os métodos herdados desta classe.
+
+ * A classe do teste funcional é salva num arquivo PHP chamado `XyzTest.php`.
+ Por convenção, o arquivo do teste funcional pode ser armazenado no diretório
+ `protected/tests/functional`.
+
+ * A classe de teste contém principalmente um conjunto de métodos de teste
+ chamados como `testAbc`, onde `Abc` geralmente é o nome de uma funcionalidade
+ que será testada. Por exemplo, para testar a funcionalidade de login, podemos
+ ter um método de teste chamado `testLogin`.
+
+ * Um método de teste geralmente contém uma série de declarações que emitirão
+ comandos para o Selenium RC interagir com a aplicação Web que está sendo
+ testada. Também contém declarações de asserção para verificar que a aplicação
+ Web responde conforme o esperado.
+
+Antes de explicarmos como escrever um teste funcional, observaremos o arquivo
+`WebTestCase.php` gerado pelo comando `yiic webapp`. Este arquivo define a
+classe `WebTestCase` que pode servir como a classe-mãe de todas as classes de
+testes funcionais.
+
+~~~
+[php]
+define('TEST_BASE_URL','http://localhost/yii/demos/blog/index-test.php/');
+
+class WebTestCase extends CWebTestCase
+{
+ /**
+ * Configura antes que cada método de teste seja executado.
+ * Define principalmente a URL base da aplicação de testes.
+ */
+ protected function setUp()
+ {
+ parent::setUp();
+ $this->setBrowserUrl(TEST_BASE_URL);
+ }
+
+ ......
+}
+~~~
+
+A classe `WebTestCase` define principalmente a URL base de todas as páginas que
+serão testadas. Mais adiante, nos métodos de teste, podemos usar URLs relativas
+para especificar quais páginas serão testadas.
+
+Também devemos prestar atenção se usamos na URL base de testes o arquivo
+`index-test.php` como script de entrada ao invés de `index.php`. A única
+diferença entre `index-test.php` e `index.php` é que o primeiro usa a
+configuração de aplicação `test.php` enquanto o segundo usa `main.php`.
+
+Agora descrevemos como testar a funcionalidade de mostrar um post no
+[exemplo de blog](http://www.yiiframework.com/demos/blog). Primeiro escrevemos a
+classe de teste como segue, observando que ela estende da classe-mãe que
+acabamos de mostrar:
+
+~~~
+[php]
+class PostTest extends WebTestCase
+{
+ public $fixtures=array(
+ 'posts'=>'Post',
+ );
+
+ public function testShow()
+ {
+ $this->open('post/1');
+ // verifica se o título do post de exemplo existe
+ $this->assertTextPresent($this->posts['sample1']['title']);
+ // verifica se o formulário de comentários existe
+ $this->assertTextPresent('Leave a Comment');
+ }
+
+ ......
+}
+~~~
+
+Como ao escrever classes de testes unitários, nós declaramos as fixtures que
+serão usadas por este teste. Aqui indicamos que a fixture `Post` deve ser usada.
+No método de teste `testShow`, primeiros instruimos o Selenium RC a acessar a
+URL `post/1`. Observe que esta é uma URL relativa, e que a URL completa é
+formada adicionando-a à URL base que configuramos na classe-mãe (ou seja,
+`http://localhost/yii/demos/blog/index-test.php/post/1`). Então verificamos que
+podemos encontrar o título do post `sample1` na página da Web atual. E nós
+também verificamos que a página contém o texto `Leave a Comment` (deixe um
+comentário).
+
+> Tip|Dica: Antes de rodar os testes funcionais, o servidor do Selenium-RC deve
+estar iniciado. Isso pode ser feito executando-se o comando
+`java -jar selenium-server.jar` dentro do diretório de instalação do servidor do
+Selenium.
+
+<div class="revision">$Id$</div>
View
157 docs/guide/pt_br/test.overview.txt
@@ -0,0 +1,157 @@
+Testes
+=======
+
+Testes são um processo indispensável do desenvolvimento de software. Estando
+conscientes disso ou não, nós conduzimos testes o tempo todo enquanto
+desenvolvemos uma aplicação Web. Por exemplo, quando escrevemos uma classe em
+PHP, podemos usar algum comando `echo` ou `die` para mostrar que implementamos
+um método corretamente; quando implementamos uma página da Web contendo um
+formulário HTML complexo, nós podemos tentar digitar alguns dados de teste para
+termos certeza de que a página interage conosco da maneira esperada.
+Desenvolvedores mais avançados escreveriam algum código para automatizar esse
+processo de testes de modo que toda vez que precisarmos testar alguma coisa,
+só precisamos chamar o código e deixar que o computador realize os testes por
+nós. Isso é conhecido como *testes automatizados*, que é o assunto principal
+deste capítulo.
+
+O suporte a testes fornecido pelo Yii inclui *testes unitários* e
+*testes funcionais*.
+
+Um teste unitário verifica que uma única unidade de código está funcionando
+conforme o esperado. Na programação orientada a objetos, a unidade de código
+mais básica é uma classe. Desta forma, um teste unitário precisa principalmente
+verificar que cada um dos métodos da interface da classe funcionam
+adequadamente. Ou seja, dados diferentes parâmetros de entrada, o teste verifica
+se o método retorna os resultados esperados. Testes unitários geralmente são
+desenvolvidos pelas pessoas que escrevem as classes sendo testadas.
+
+Um teste funcional verifica que uma funcionalidade (por exemplo, gerenciamento
+de posts em um sistema de blog) está funcionando conforme o esperado. Comparado
+com um teste unitário, um teste funcional está em um nível superior, porque
+uma funcionalidade sendo testada frequentemente envolve múltiplas classes.
+Testes funcionais geralmente são desenvolvidos por pessoas que conhecem muito
+bem os requisitos do sistema (elas poderiam ser tanto desenvolvedores quanto
+engenheiros de qualidade).
+
+
+Desenvolvimento Orientado a Testes
+-----------------------
+
+A seguir mostramos os ciclos de desenvolvimento no assim chamado
+[desenvolvimento orientado a testes (TDD)](http://en.wikipedia.org/wiki/Test-driven_development):
+
+ 1. Crie um novo teste que cubra uma funcionalidade que será implementada.
+ Espera-se que o teste falhe em sua primeira execução, porque a
+ funcionalidade ainda precisa ser implementada.
+ 2. Rode todos os testes e certifique-se de que o novo teste falha.
+ 3. Escreva código para fazer o novo teste passar.
+ 4. Rode todos os testes e certifique-se de que todos passam.
+ 5. Refatore o código que foi recém-escrito e certifique-se de que todos os
+ testes ainda passam.
+
+Repita os passos de 1 a 5 para avançar na implementação de funcionalidades.
+
+
+Configuração do Ambiente de Teste
+----------------------
+
+Os testes suportados fornecidos pelo Yii requerem
+[PHPUnit](http://www.phpunit.de/) 3.5+ e
+[Selenium Remote Control](http://seleniumhq.org/projects/remote-control/) 1.0+.
+Por favor, consulte as suas documentações sobre como instalar o PHPUnit e o
+Selenium Remote Control.
+
+Quando usamos o comando de console `yiic webapp` para criar uma nova aplicação
+Yii, ele gerará automaticamente os seguintes arquivos e diretórios para nós,
+para escrevermos e realizarmos novos testes:
+
+~~~
+testdrive/
+ protected/ contendo arquivos da aplicação protegidos
+ tests/ contendo testes para a aplicação
+ fixtures/ contendo fixtures do banco de dados
+ functional/ contendo testes funcionais
+ unit/ contendo testes unitários
+ report/ contendo relatórios de cobertura
+ bootstrap.php o script executado logo no início
+ phpunit.xml o arquivo de configuração do PHPUnit
+ WebTestCase.php a classe base para testes funcionais baseados na Web
+~~~
+
+Conforme mostrado acima, nosso código de testes será posto principalmente em
+três diretórios: `fixtures`, `functional` e `unit`, e o diretório `report` será
+usado para armazenar os relatórios de cobertura do código gerados.
+
+Para executar os testes (sejam testes unitários ou funcionais), podemos executar
+os seguintes comandos na janela do console:
+
+~~~
+% cd testdrive/protected/tests
+% phpunit functional/PostTest.php // executa um teste individual
+% phpunit --verbose functional // executa todos os testes em 'functional'
+% phpunit --coverage-html ./report unit
+~~~
+
+O último dos comandos acima executará todos os testes que estão no diretório
+`unit` e gerará um relatório de cobertura de código no diretório `report`.
+Note que a [extensão xdebug](http://www.xdebug.org/) precisa estar instalada e
+ativa para gerar relatórios de cobertura de código.
+
+
+Script de Inicialização dos Testes
+--------------------
+
+Vamos observar o que deve haver no arquivo `bootstrap.php`. Este arquivo é tão
+especial porque ele é como o [script de entrada](/doc/guide/basics.entry) e
+é o ponto de partida quando executamos um conjunto de testes.
+
+~~~
+[php]
+$yiit='path/to/yii/framework/yiit.php';
+$config=dirname(__FILE__).'/../config/test.php';
+require_once($yiit);
+require_once(dirname(__FILE__).'/WebTestCase.php');
+Yii::createWebApplication($config);
+~~~
+
+No código acima, primeiro incluímos o arquivo `yiit.php` do framework Yii, que
+inicializa algumas constantes globais e inclui todas as classes-mãe de teste
+necessárias. Então criamos uma instância da aplicação Web usando o arquivo de
+configuração `test.php`. Se checarmos o `test.php`, descobriremos que ele herda
+do arquivo de configuração `main.php` e adiciona um componente de aplicação
+`fixture` cuja classe é [CDbFixtureManager]. Nós descreveremos as fixtures em
+dealhes na próxima seção.
+
+~~~
+[php]
+return CMap::mergeArray(
+ require(dirname(__FILE__).'/main.php'),
+ array(
+ 'components'=>array(
+ 'fixture'=>array(
+ 'class'=>'system.test.CDbFixtureManager',
+ ),
+ /* descomente o seguinte para prover uma conexão com o banco de dados de teste
+ 'db'=>array(
+ 'connectionString'=>'DSN do banco de dados de teste',
+ ),
+ */
+ ),
+ )
+);
+~~~
+
+Quando rodamos testes que envolvem o banco de dados, devemos fornecer um banco
+de dados de teste, de modo que a execução do teste não interfira com as
+atividades normais do desenvolvimento ou da produção. Para fazê-lo, só
+precisamos descomentar a configuração `db` no trecho acima e preencher a
+propriedade `connectionString` com o DSN (nome da fonte de dados) do banco de
+dados de testes.
+
+Com esse script de inicialização, quando rodamos os testes unitários, teremos
+uma instância da aplicação que é aproximadamente a mesma que responde às
+requisições Web. A diferença principal é que ela tem o gerenciador de fixtures
+e está usando o banco de dados de testes.
+
+
+<div class="revision">$Id$</div>
View
120 docs/guide/pt_br/test.unit.txt
@@ -0,0 +1,120 @@
+Testes Unitários
+============
+
+Uma vez que o framework de testes do Yii é construído em cima do
+[PHPUnit](http://www.phpunit.de/), é recomendado que você primeiro consulte
+[sua documentação](http://www.phpunit.de/manual/current/en/index.html)
+para entender o básico sobre como escrever um teste unitário. Nós
+resumimos a seguir os princípios básicos de escrita de um teste unitário no Yii:
+
+ * Um teste unitário é escrito em termos de uma classe `XyzTest` que estende de
+ [CTestCase] ou [CDbTestCase], onde `Xyz` representa a classe sendo testada.
+ Por exemplo, para testar a classe `Post`, por convenção devemos chamar a
+ classe de teste unitário correspondente de `PostTest`. A classe-mãe
+ [CTestCase] é destinada para testes unitários genéricos, enquanto a
+ [CDbTestCase] é adequada para testar classes de modelo
+ [active record](/doc/guide/database.ar). Já que `PHPUnit_Framework_TestCase`
+ é a classe-mãe de ambas as classes, nós podemos usar todos os métodos
+ herdados desta classe.
+
+ * A classe de teste unitário é salva em um arquivo PHP chamado de
+ `XyzTest.php`. Por convenção, o arquivo de teste unitário pode ser armazenado
+ no diretório `protected/tests/unit`.
+
+ * A classe de teste contém na maior parte um conjunto de métodos de teste
+ chamados como `testAbc`, onde `Abc` geralmente é o nome do método da classe
+ que será testado.
+
+ * Um método de teste geralmente contém uma série de métodos de asserção (por
+ exemplo, `assertTrue`, `assertEquals`) que servem como checkpoints ao
+ validar o comportamento da classe alvo.
+
+
+A seguir, descrevemos principalmente como escrever testes unitários para classes
+de modelo [active record](/doc/guide/database.ar). Estenderemos as nossas
+classes de [CDbTestCase] porque ela fornece o suporte às fixtures de banco de
+dados que introduzimos na seção anterior.
+
+Suponha que queremos testar a classe do modelo `Comment` (comentário) no
+[exemplo de blog](http://www.yiiframework.com/demos/blog/). Começamos criando
+uma classe chamada de `CommentTest` e a salvando como
+`protected/tests/unit/CommentTest.php`:
+
+~~~
+[php]
+class CommentTest extends CDbTestCase
+{
+ public $fixtures=array(
+ 'posts'=>'Post',
+ 'comments'=>'Comment',
+ );
+
+ ......
+}
+~~~
+
+Nesta classe, especificamos o atributo `fixtures` como um array que especifica
+quais fixtures serão usadas por este teste. O array representa um mapeamento
+dos nomes das fixtures aos nomes das classes de modelo ou aos nomes das tabelas
+das fixtures (por exemplo, do nome de fixture `posts` para a classe de modelo
+`Post`). Note que ao mapear para nomes de tabelas de fixtures, devemos prefixar
+o nome da tabela com dois pontos (por exemplo, `:Post`) para diferenciá-lo dos
+nomes de classe de modelo. E ao usar nomes de classes de modelo, as tabelas
+correspondentes serão consideradas como tabelas de fixtures. Conforme
+descrevemos anteriormente, as tabelas das fixtures serão resetadas a algum
+estado conhecido toda vez que um método de teste for executado.
+
+Os nomes das fixtures nos permitem acessar os seus dados nos métodos de teste de
+uma maneira conveniente. O código a seguir demonstra a sua típica utilização:
+
+~~~
+[php]
+// retorna todas as linhas na tabela da fixture 'Comment'
+$comments = $this->comments;
+// retorna a linha cujo alias é 'sample1' na tabela da fixture `Post`
+$post = $this->posts['sample1'];
+// retorna a instância de AR representando a linha de dados 'sample1'
+$post = $this->posts('sample1');
+~~~
+
+> Note|Nota: Se uma fixture for declarada usando seu nome de tabela (por
+exemplo, `'posts'=>':Post'`), então o terceiro uso acima não é válido porque nós
+não temos informações sobre com qual classe de modelo a tabela está associada.
+
+Em seguida, escrevemos o método `testApprove` para testar o método `approve` na
+classe de modelo `Comment`. O código é bastante claro: primeiro inserimos um
+comentário de status pendente; então verificamos que este comentário está em
+status pendente retornando ele do banco de dados; e finalmente chamamos o método
+`approve` e verificamos se o status mudou conforme o esperado.
+
+~~~
+[php]
+public function testApprove()
+{
+ // insere um comentário de status pendente
+ $comment=new Comment;
+ $comment->setAttributes(array(
+ 'content'=>'comment 1',
+ 'status'=>Comment::STATUS_PENDING,
+ 'createTime'=>time(),
+ 'author'=>'me',
+ 'email'=>'me@example.com',
+ 'postId'=>$this->posts['sample1']['id'],
+ ),false);
+ $this->assertTrue($comment->save(false));
+
+ // verifica se o comentário está em status pendente
+ $comment=Comment::model()->findByPk($comment->id);
+ $this->assertTrue($comment instanceof Comment);
+ $this->assertEquals(Comment::STATUS_PENDING,$comment->status);
+
+ // chama approve() e verifica se o comentário tem o status aprovado
+ $comment->approve();
+ $this->assertEquals(Comment::STATUS_APPROVED,$comment->status);
+ $comment=Comment::model()->findByPk($comment->id);
+ $this->assertEquals(Comment::STATUS_APPROVED,$comment->status);
+}
+~~~
+
+
+<div class="revision">$Id$</div>
View
2 docs/guide/pt_br/toc.txt
@@ -16,7 +16,7 @@
- [Visão](basics.view)
- [Componentes](basics.component)
- [Módulo](basics.module)
- - [Path Alias and Namespace](basics.namespace)
+ - [Path Alias e Namespace](basics.namespace)
- [Convenções](basics.convention)
- [Fluxo de Trabalho](basics.workflow)
- [Melhores Práticas em MVC](basics.best-practices)
View
67 docs/guide/pt_br/upgrade.txt
@@ -0,0 +1,67 @@
+Atualizando a versão 1.0 para 1.1
+=================================
+
+Mudanças Relacionadas a Cenários de Modelos
+------------------------------------
+
+- Removido o método CModel::safeAttributes(). Atributos seguros agora são
+definidos por aqueles que estão sendo validados por alguma regra conforme
+definidas em CModel::rules() para o cenário em particular.
+
+- Alterados os métodos CModel::validate(), CModel::beforeValidate() e
+CModel::afterValidate(). CModel::setAttributes(),
+CModel::getSafeAttributeNames(). O parâmetro 'scenario' foi removido. Você deve
+obter e setar o cenário do modelo através de CModel::scenario.
+
+- Alterado o CModel::getValidators() e removido
+CModel::getValidatorsForAttribute(). CModel::getValidators() agora só retorna os
+validadores que se aplicam ao cenário conforme especificado na propriedade
+scenario do modelo.
+
+- Alterados o CModel::isAttributeRequired() e
+CModel::getValidatorsForAttribute(). O parâmetro scenario foi removido. Ao invés
+disso, será usada a propriedade scenario do modelo.
+
+- Removido o CHtml::scenario. CHtml usará o cenário do modelo ao invés disso.
+
+
+Mudanças Relacionadas a Eager Loading para Active Record Relacional
+---------------------------------------------------------------
+
+- Por padrão uma única declaração JOIN será gerada e executada para todos os
+relacionamentos envolvidos no eager loading. Se a tabela principal tiver as
+suas opções `LIMIT` ou `OFFSET` definidas, ela será consultada sozinha primeiro,
+seguida por outra declaração SQL que retorna todos os objetos relacionados.
+Antes disso na versão 1.0.x, o comportamento padrão é que haveriam `N+1`
+declarações SQL se um eager loading envolvesse `N` relacionamentos
+`HAS_MANY` ou `MANY_MANY`.
+
+Mudanças Relacionadas a Alias de Tabelas no Active Record Relacional
+------------------------------------------------------------
+
+- O alias padrão para uma tabela relacional agora é o mesmo que o nome da
+relação. Anteriormente, na versão 1.0.x, o Yii por padrão automaticamente
+geraria um alias de tabela para cada tabela relacional, e tínhamos de usar
+o prefixo `??.` para nos referir a este alias gerado automaticamente.
+
+- O nome do alias para a tabela principal em uma query do AR foi fixado como
+sendo `t`. Anteriormente, na versão 1.0.x, era o mesmo que o nome da tabela.
+Isso fará co mque o código de queries de AR existentes deixem de funcionar se
+eles explicitamente especificam prefixos de coluna usando o nome da tabela.
+A solução é substituir esses prefixos com 't.'.
+
+
+Mudanças Relacionadas a Entrada Tabular
+----------------------------------
+
+- Não é mais válido usar `Field[$i]` para nomes de atributos, eles deveriam ser
+como `[$i]Field` de modo a suportar campos do tipo array (por exemplo,
+`[$i]Field[$index]`).
+
+Outras Mudanças
+-------------
+
+- A assinatura do construtor da [CActiveRecord] mudou. O primeiro parâmetro
+(a lista de atributos) foi removido.
+
+<div class="revision">$Id$</div>

0 comments on commit dc6aae5

Please sign in to comment.