BDD em código produtivo com Python
2 views
Skip to first unread message
Douglas Cardoso
9:16 AM (4 hours ago) 9:16 AM
to Python Brasil
Olá, parabéns aos idealizadores do projeto. Tenho visto muitas discussões produtivas e respeistosas (coisa que não vejo em outras comunidades). Sou professor de automação de testes da PUC Minas e estou explorando uma nova abordagem em BDD que chamo de 'narrativa executável'. Uso está abordagem para ensinar automação de testes aos meus alunos e estou buscando opiniões sinceras de especialistas em Python para refinar e melhorar a abordagem de ensino e o framework Python desenvolvido. O framework que uso nas minhas aulas se chama Guará, é open source e tem contribuição da comunidade Python. Ele usa o padrão de projetos Page Transactions onde o foco da automação sai da UI e se volta para a jornada do usuário.
O cenário de testes implementado no padrão ficaria algo como (simplificado para facilitar a leitura):
app.given(TheUserIsLoggedIn, with_name='john.doe').when(TheUserBuysAProduct, with_name='cellphone').then(TheSystemShouldReturn, 'done')
Note que o cenário é todo escrito em Python puro, mas mantém a narrativa de negócio. Como uso Python, posso usar todas as tecnicas de programação OO como herança, sobrecarga de métodos, sobreescrita de método, etc.. Portanto, consigo escrever o código em português (e qualquer outra língua) usando herança
app.dado(UmUsuárioLogado, com_nome='john.doe').quando(OUsuarioCompraUmProduto, com_nome='cellphone').entao(OSistemaDeveRetornar, 'done')`
Posso usar linguagem ubíqua reforçando a prática de DDD (Domain-Driven Design) em um projeto.
eduapp.sabido_que(ExistaUmAluno, de_nome='Fulano de Tal').uma_vez_que(OAlunoSeInscreveNaMateria, de_nome='Matemática').logo(EleDeveEstar, 'Matriculado')
Posso criar novas asserções que alimentam o método `then` (e suas variações). Enfim, o testador é livre para estender o framework como ele queira.
Porém, dadas as possibilidades do framework, tenho explorado uma abordagem diferente do BDD que não passa pelos testes. Note que eu posso usar o cenário como parte do meu código fonte usando uma metalinguagem que estabelece um contrato onde given é a pré-condição, when a execução e then é a pós-condição. Considere a função abaixo como parte de uma implementação de uma CLI.
def inscrever_aluno_na_materia(aluno, materia):
eduapp.sabido_que(ExistaUmAluno, de_nome=aluno) \
.uma_vez_que(OAlunoSeInscreveNaMateria, de_nome=materia) \
.logo(EleDeveEstar, 'Matriculado')
chamando a função por uma CLI no terminal ficaria como:
python main.py inscrever-aluno-na-materia --aluno 'Fulano de Tal' --materia Matemática
Gostaria da opnião da comunidade sobre essa nova abordagem BDD e sobre o framework.
Notas:
- Eu pesquisei outras ferramentas BDD onde se escreve o código puro, como JGiven (Java), mas ele ainda é focado no teste em si.
- A camada extra não elimina a necessidade de services, repositories, models... mas deixa o código fonte mais orientado à intenção do negócio. Ele também vira a propria documentação e fonte de verdade.
Acham que a abordagem faz sentido?
A intenção do código mais clara com a camada extra?
Deixem comentários livres, por favor
Vou deixar alguns links extras caso tenham interesse no meu trabalho. Abraços!
Pessoais
Sobre o projeto
O cenário de testes implementado no padrão ficaria algo como (simplificado para facilitar a leitura):
app.given(TheUserIsLoggedIn, with_name='john.doe').when(TheUserBuysAProduct, with_name='cellphone').then(TheSystemShouldReturn, 'done')
Note que o cenário é todo escrito em Python puro, mas mantém a narrativa de negócio. Como uso Python, posso usar todas as tecnicas de programação OO como herança, sobrecarga de métodos, sobreescrita de método, etc.. Portanto, consigo escrever o código em português (e qualquer outra língua) usando herança
app.dado(UmUsuárioLogado, com_nome='john.doe').quando(OUsuarioCompraUmProduto, com_nome='cellphone').entao(OSistemaDeveRetornar, 'done')`
Posso usar linguagem ubíqua reforçando a prática de DDD (Domain-Driven Design) em um projeto.
eduapp.sabido_que(ExistaUmAluno, de_nome='Fulano de Tal').uma_vez_que(OAlunoSeInscreveNaMateria, de_nome='Matemática').logo(EleDeveEstar, 'Matriculado')
Posso criar novas asserções que alimentam o método `then` (e suas variações). Enfim, o testador é livre para estender o framework como ele queira.
Porém, dadas as possibilidades do framework, tenho explorado uma abordagem diferente do BDD que não passa pelos testes. Note que eu posso usar o cenário como parte do meu código fonte usando uma metalinguagem que estabelece um contrato onde given é a pré-condição, when a execução e then é a pós-condição. Considere a função abaixo como parte de uma implementação de uma CLI.
def inscrever_aluno_na_materia(aluno, materia):
eduapp.sabido_que(ExistaUmAluno, de_nome=aluno) \
.uma_vez_que(OAlunoSeInscreveNaMateria, de_nome=materia) \
.logo(EleDeveEstar, 'Matriculado')
chamando a função por uma CLI no terminal ficaria como:
python main.py inscrever-aluno-na-materia --aluno 'Fulano de Tal' --materia Matemática
Gostaria da opnião da comunidade sobre essa nova abordagem BDD e sobre o framework.
Notas:
- Eu pesquisei outras ferramentas BDD onde se escreve o código puro, como JGiven (Java), mas ele ainda é focado no teste em si.
- A camada extra não elimina a necessidade de services, repositories, models... mas deixa o código fonte mais orientado à intenção do negócio. Ele também vira a propria documentação e fonte de verdade.
Acham que a abordagem faz sentido?
A intenção do código mais clara com a camada extra?
Deixem comentários livres, por favor
Muito obrigado!
Pessoais
Sobre o projeto
Reply all
Reply to author
Forward
0 new messages