Closed maurogeorge closed 12 years ago
Concordo plenamente. Testes são importantes. Com isso podemos integrar com o Travis CI.
+1 subscribe
@maurogeorge
Tem como você elaborar um draft sobre esse tópico para ser apresentado como uma proposta de inserção à documentação e guidelines do projeto, conforme discutido em https://github.com/BielSystems/boletophp/issues/14
@fabiorphp
Meu eu não conhecia o Travis CI, tava lendo a documentação dele e gostei do conceito, muito bacana mesmo essa ideia de testar aplicações literalmente nas nuvens.
Que tal você tomar a frente neste tópico e escrever sobre o assunto para colocar na documentação e guidelines do nosso projeto que está sendo discutido em https://github.com/BielSystems/boletophp/issues/14
Ainda não entendo muito, pois só apliquei em um projeto. Vou elaborar algo e posto pra vocês.
Olá eu sou o desenvolvedor do pyboleto. https://github.com/eduardocereto/pyboleto
O escopo do projeto é o mesmo porém em Python e hoje faz apenas impressão de boletos em pdf, estou implementando para HTML tb. O código está mais organizado e mais testado que o phpboleto. Talvez interesse para você @maurogeorge dar uma olhada e talvez se basear na mesma estrutura. Seria ótimo se o pyboleto e o boletophp tivessem uma estrutura parecida que facilitasse portar código de um para o outro.
Em comparação com o boletophp o pyboleto suporta bem menos bancos, mas estou tentando portar o suporte de alguns bancos do phpboleto para o pyboleto.
Bom trabalho
Olá @eduardocereto muito boa a sua iniciativa.
Quanto a manter a mesma estrutura, não sei se é isto que quer dizer, tipo nome de pastas, arquivos etc. É complicado, pois no python temos a PEP 8 e no PHP temos as PSR 0 1 e 2.
O que eu estou fazendo no momento no meu branch é portar o código sem testes para um em orientação a objetos e testado. Inclusive, neste primeiro momento, para ajudar no port estou mantendo os nomes de variaveis, métodos, sem levar em conta as PSR, pois como terá testes depois que portar sem seguir a PSR eu posso refatorar para ficar de acordo.
Mais concerteza, um projeto podera ajudar o outro, como por exemplo para ver implementação de boletos.
@maurogeorge quando eu falei se basear na mesma estrutura eu estava falando mais em termos de OO.
No pyboleto temos um módulo chamado pyboleto.data
que tem as informações genéricas para montagem de boletos e depois temos as customizações por banco que moram por exemplo em pyboleto.bank.bradesco
.
Talvez valha a pena você dar uma olhada no que eu generalizo. Se fosse parecido seria mais fácil portar implementações entre boletophp e pyboleto. Mas é só uma sugestão visto que você esta refazendo a estrutura.
Olá @eduardocereto
Eu não tenho familiaridade com o Python mas estou brincando com ela pois quero trabalhar com o OpenERP.
Só para você ficar ciente, caso ainda não saiba, dê uma uma olhada neste meu repositório aqui https://github.com/drupalista-br/Boleto/blob/1.x-dev/README.md ( eu criei um redirecionador para facilitar a memorização www.boletolibraryphp.co.cc ).
t+
@eduardocereto entendi o seu ponto agora. Nisso acredito que ficará bem parecido sim. No meu branch tenho a classe abstrata boleto que tem as informações genéricas, e as especificas como o boleto da caixa.
Sim, valerá apena ver o que você generaliza, no entanto pelo menos no meu branch ainda não é o momento, pelo motivo que explico melhor aqui. Que como estou migrando do procedural para o OO, neste primeiro momento estou mantendo o nome e implementação igual ao procedural. Depois que implementar todos os boletos em OO, ai começa a ficar legal, para refatorar e decidir o que especializar etc.
Fechando a issue pois no branch 2.x-dev o código está sendo testado e só entra código novo com testes.
Na minha opinião o ideal é que o que for desenvolvido para a nova versão seja devidamente testado com o PHPUnit. Para não cairmos no mesmo problema do branch procedural em que fica muito complicado alterar ou refatorar devido a não saber se estamos quebrando algo. E como o projeto está seguindo este caminho de orientação a objeto proponho os testes agora no inicio, para não precisar testar tudo no final como esta sendo feito no procedural agora, se não acabaremos caindo no mesmo problema de não ter testes.