Apesar de o Composer estar por aí há algum tempo, muitos pacotes ainda estão em sua infância (< 1.0) ou às vezes não têm tantos recursos como poderiam ter. Para ser sincero, sempre há mais para ser feito, ou fazer o mesmo de forma mais eficiente.

Qualquer que seja o caso, pull requests serão coisas comuns para a comunidade PHP estar fazendo com esses pacotes, e isso precisa ser feito de forma segura, com testes unitários.

Então, como você executa a suíte de testes deles e acrescenta seus próprios testes?

Compondo o Composer

Você vai querer ir dois níveis abaixo e instalar o composer dentro do próprio pacote:

cd myapp/vendor/laravel/framework
curl -sS https://getcomposer.org/installer | php

Se você instalou o Composer globalmente ao renomeá-lo para /usr/bin/composer, então você pode pular essa parte.

Depois, você deve executar o Composer e instalar todos os pacotes de dependências. Normalmente, isso vai se juntar à sua pasta /myapp/vendor/ quando você executar a instalação principal do composer, mas isso vai instalar todos os pacotes e qualquer coisa de desenvolvimento para completar seus testes unitários no diretório atual:

./composer.phar install --dev

Testando o pacote

Com as dependências –dev instaladas, você pode facilmente executar qualquer suíte de testes que o desenvolvedor do pacote tenha configurado – que é mais provável que seja (ao menos) o PHPUnit.

./vendor/bin/phpunit

Isso deve rodar os testes deles, desde que o pacote core tenha um arquivo phpunit.xml. Se o phpunit.xml estiver em outro lugar (talvez em uma pasta build/ para o Jenkins ou sei lá), então passe a localização com a opção -c:

./vendor/bin/phpunit -c build/phpunit.xml

É importante executar isso antes de começar a gastar tempo com o código deles, porque escrever seu próprio código fica muito mais difícil se o deles não está nem funcionando.

Se receber um sinal vermelho antes de fazer qualquer correção, ENTÃO trabalhe na própria feature (ou desista e encontre um pacote melhor, qualquer um dos dois).

Acrescentando testes

Recebeu um sinal verde? Ótimo.

A ordem na qual você faz o próximo pedaço é totalmente irrelevante, mas eu gosto de escrever o teste antes, e então escrever o código:

public function testSort()
{
    $data = new Collection(array(5, 3, 1, 2, 4));
    $data->sort(function($a, $b)
    { 
        if ($a === $b)
        {
            return 0;
        }
        return ($a < $b) ? -1 : 1;
    });

$this->assertEquals(range(1, 5), array_values($data->all()));

}

Isso foi um novo método para a classe Support\Collection do Laravel 4, que permite que você faça um uasort() em uma Coleção. Não é nada complicado, mas o Taylor não vai fazer o merge disso sem testes, na maior parte porque ele sabe do que eu gosto.

Executar isso novamente acende um grande sinal vermelho, porque o método nem mesmo existe. Portanto, escrevo o método, me atrapalho com alguns erros e então ele fica verde. ISSSA!

Enviando o Pull Request

Você escreveu a feature. Hora de compartilhá-la com o mundo!

Vá até o repositório principal (nesse caso, github.com/laravel/framework) e clique em Fork. Copie a URL Git+SSH e então pule para o terminal e digite isto:

git checkout -b feature/kittens
git add src/Fluffy.php src/Snuggles.php
git commit -m "More kittens."
git push git@github.com:philsturgeon/framework.git feature/kittens

Atualize sua página de repositório e verá o botão Pull Request próximo do branch que você enviou. Clique nele, escreva uma mensagem e pronto.

Usando seu fork

Haverá algum tempo entre a submissão do seu Pull Request e a entrada dele em uma versão para que você use, e é necessário que você não se preocupe com isso. Alguns projetos fazem o merge rápido, alguns demoram mais. Às vezes, é porque o pacote tem ciclos demorados e, às vezes, a pessoa responsável é apenas chata. Ninguém sabe.

O Composer está completamente pronto para te auxiliar aqui de qualquer forma.

{
    "repositories": [
        {
            "type": "vcs",
            "url": "git://github.com/philsturgeon/framework.git"
        }
    ],
    "require": {
        "laravel/framework": "dev-feature/kittens",
        "other/stuff" : "1.0.*@stable"
    },
    "minimum-stability": "dev"
}

Agora, quando você digitar um composer update, estará na verdade usando a sua versão do código, não a deles. Isso significa que você poderá esperar o tempo que for.

Você pode até mesmo fazer o merge de todos esses branches individuais no branch master do seu fork para utilizar todas as suas mudanças ao mesmo tempo, sem ter que atormentar eles com o mesmo pull request.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://philsturgeon.co.uk/blog/2013/05/testing-contributing-composer-packages