Release contínuo de um microsserviço com Docker ASP.net core e Azure Containe...
BDD no mundo real
1. Behavior-Driven Development (BDD) no mundo real Giovanni Bassi Lambda3 Lambda3 | MVP | Scrum Developer Trainer | Scrum Trainer giovanni@lambda3.com.br | unplugged.giggio.net | lambda3.com.br
25. Trocar de senha Enquanto usuário Eu quero trocar de senha Para que eu possa garantir minha segurança
26. Trocar de senha Dado... Quando... Então... Um usuário logado Solicito a troca de senha A senha é alterada E ativo E a nova senha é válida Um usuário logado Solicito a troca de senha A senha não é alterada E ativo E a nova senha é inválida Um usuário anônimo Solicito a troca de senha Um erro é lançado Cenário 1 Cenário 2 Cenário 3 Funcionalidade
31. Diz o que quer Captura de maneira abstrata Contribui com cenários concretos Escreve o código com BDD EN AN Dev T Feedback
32.
33.
34. Fotografia da cultura de testes e BDD .Net Java Ruby Principalmente NUNit e MSTest, para testes de unidade e de integração. Moq e RhinoMocks para Mocks. BDD com StoryQ, SpecFlow, NBehave e MSpec. Cultura de testes ainda é incipiente. jUnit para testes de unidade e de integração e Selenium para testes de aceitação. jBehave e Calopsita para BDD, mas é raro. jMock e Mockito para Mocks. Cultura de testes varia. TestUnit, RSpec, Cucumber e Shoulda são os mais usados. Testes de unidade e integrado ao longo de toda a stack. Não precisa de framework específico de Mocks. BDD faz parte da cultura de boa parte dos rubistas e testes são muito comuns.
36. Um usuário logado Solicito a troca de senha A senha é alterada E ativo E a nova senha é válida Um usuário logado Solicito a troca de senha A senha não é alterada E ativo E a nova senha é inválida Um usuário anônimo Solicito a troca de senha Um erro é lançado Rendimentos decrescentes
39. public class UserStory extends DefaultStory { @Test public void signUpWithANewUser() { given .theUserDoesntExist( "ceci" ); given .iAmOnTheRootPage(); when .iSignUpAs( "ceci" ); then .iMustBeLoggedInAs( "ceci" ); } }
40. public class GivenContexts { public void iAmOnTheRootPage() { browser.open( "/calopsita" ); } public void theUserDoesntExist( String name) { session.createQuery( "delete from User u where u.name = :name" ) .setParameter( "name" , name) .executeUpdate(); } }
41. public class WhenActions { public void iSignUpAs( String login) { iClickOn( "Sign Up" ); Form form = browser.currentPage().form( "signUp" ); form.field( "user.name" ).type(login); form.field( "user.login" ).type(login); form.field( "user.email" ).type(login + "@caelum.com.br" ); form.field( "user.password" ).type(login); form.field( "user.confirmation" ).type(login); form.submit(); } }
42. public class ThenAsserts { public void iMustBeLoggedInAs( String login) { ContentTag div = div( "user" ); assertThat(div, allOf( containsText(login), containsText( "Logout" ))); } }
43.
44. public abstract class AccountSpecs { protected static Account fromAccount; protected static Account toAccount; Establish context =()=> { fromAccount = new Account {Balance = 1m}; toAccount = new Account {Balance = 1m}; }; } [ Subject ( typeof ( Account ), "Funds transfer" )] public class when_transferring_between_two_accounts : AccountSpecs { Because of = () => fromAccount.Transfer(1m, toAccount); It should_debit_the_from_account_by_the_amount_transferred = () => fromAccount.Balance.ShouldEqual(0m); It should_credit_the_to_account_by_the_amount_transferred = () => toAccount.Balance.ShouldEqual(2m); }
45.
46.
47.
48.
49.
Hinweis der Redaktion
7 minutos até aqui
Com ADD, você assume que: Vai precisar do código que está escrevendo Sabe o que o cliente precisa Sabe que o código funciona
Não tem nada a ver com testes...
Porque chamamos de testes se não estamos fazendo isso para os testes? BDD é uma nova maneira de ver as coisas Podíamos fazer tudo com TDD antes, mas o mindset impedia Dan North criou o BDD para resolver o problema de mindset 12 minutos
BDD != TDD principalmente porque o vemos de forma diferente
Porque perguntamos o porque
Convite à discussão
Estamos falando de lucro e de ROI
Voltando ao fluxo...
16 minutos
Acerte as palavras também vale na linguagem com o cliente BDD vai te obrigar a pensar no negócio, modelar o negócio
Nada melhor que DDD pra isso
19 minutos
Nivel de detalhe dos cenários Não deve virar um caso de uso, com regras, etc
Dev e Tester pareiam, etc... EN: Especialista de negócio DEV: desenvolvedor T: Testador AN: Analista de negócio 27 minutos
Dan North diz que tem que ser unitários O mercado usa muito testes integrados Sugestão: mix de ambos, busque sua maneira, busque o que se adeque melhor à tecnologia que vc está usando De qualquer forma, o foco não é testar
Dan North diz que é pra testar interações, usando mocks Martin Fowler diz que é pra estar estado, usando stubs somente
Não pensamos ainda no que está no meio Conhecemos os cenários, que estão fora Paramos de desenvolver as coisas do meio quando os cenários são atendidos Sempre trabalhando com mocks Nunca acessar infra a partir de negócio
Evolui naturalmente Discutida ao longo do projeto 37 minu tos até aqui