- TDD: Red – Green – Refactor - Testes de Unidade x Testes de Integração - Ports and Adapters Pattern - Business Domain versus Technical Domain - Testes de Unidade com JMock - Coverage Tests - Logging Tests

3. TDD: Red – Green – Refactor

4. Testes de Unidade x Testes de Integração

6. Coverage Tests

7. Logging Tests

10. Queremos uma classe que realize autenticação (um Authenticator)

11. O ponto de partida será AuthenticatorTests

13. @Test

14. public void shouldAuthenticateWhenCredentialsAreValid() {

15. }

17. @Test

20. private final Authenticator authenticator = new Authenticator();

21. private final String validUsername = “valid@userna.me”;

22. private final String validUsername = “va1idpassw0rd”;

23. @Test

25. assertThat(“authentication response”, response, is(notNullValue()));

28. Observe o teste falhar

29. A mensagem de falha do teste expressa suficientemente bem o que está quebrado?

32. Elas ajudarão a diagnosticar problemas, quando novas features provoquem quebra de código existente.

35. KISS – Keep It Simple

36. Não perca o foco do teste.

37. Não se distraia com premissas que devem ser validadas em outros testes.

40. Resposta: Depende (nenhuma verdade é absoluta)

41. Se está interessado em criar um Domain Model, é importante separar classes de domínio das classes que possuem detalhes técnicos de como a funcionalidade é implementada.

43. Adapters: implementam as interfaces, encapsulando o domínio técnico da aplicação

44. Testes de Unidade: verificam o comportamento do Authenticator.

45. Testes de Integração: verificam a implementação do delegate.

46. Ports and Adapters Pattern (GOOS)

49. Falhar o teste : o teste falha de forma clara, facilitando o correto diagnóstico?

50. Corrigir Authenticator e AuthenticationResponse e passar

52. O Delegate responsável pela autenticação via POST/XML é injetado no Authenticator, via construtor.

53. Resta prover uma implementação do Delegate – um RestTemplateDelegate, por exemplo – e escrever um teste de integração.

54. Teste de Integração @RunWith (SpringJUnit4ClassRunner. class ) @ContextConfiguration (locations= "classpath:beans.xml" ) public class RestTemplateAuthenticatorTests { @Autowired private RestTemplateAuthenticationDelegate restTemplateDelegate ; private Authenticator authenticator ; @Before public void setup() { authenticator = new Authenticator( restTemplateDelegate ); } @Test public void authenticateUser() throws Exception { assertTrue ( authenticator .authenticate( "fab1@spam.la" , "teste123456" ).isAuthenticated()); }

55. RestTemplateAutenticationDelegate public class RestTemplateAuthenticationDelegate implements Authenticator.Delegate { private final String url ; private final RestTemplate rest ; public RestTemplateAuthenticationDelegate(String url, RestTemplate rest) { this . url = url; this . rest = rest; } public AuthenticationResponse performAuthentication(String username, String password) throws AuthenticationFailure { try { XmlAuthenticationRequest xmlRequest = new XmlAuthenticationRequest(); xmlRequest.setIp( "127.0.0.1" ); xmlRequest.setLogin(username); xmlRequest.setSenha(password); XmlAuthenticationResponse xmlResponse = rest .postForObject( url , xmlRequest, XmlAuthenticationResponse. class ); AuthenticationResponse response = new AuthenticationResponse(); response.setAuthenticated(xmlResponse.getStatus().equals( "AUTENTICADO" )); return response; } catch (Throwable e) { throw new AuthenticationFailure(e); } } }

57. Coverage Test (Eclipse Emma)

58. Manter a cobertura dos testes em nível elevado (acima de 90%) é praticamente impossível se você não pratica Test First.

59. Aumentar a cobertura de código “Test After” é muito mais difícil, e pode dar um falsa sensação de cobertura.

61. LoggingTests!

63. Deve-se dar tanta importância a testes de Logging como damos a testes de UI!

64. Não é desejável que as mensagens críticas de logging quebrem com a evolução da aplicação

65. Caso existam ferramentas automáticas de análise de log, elas irão quebrar caso o logging não seja estável com o passar do tempo.

66. Mensagens de debbuging não precisam ser testadas.

67. Deve-se selecionar com critério as mensagens críticas para a aplicação, que precisam ser testadas.

68. Tratar como Logging como Requisitos de Suporte?

70. Amarra a implementação à biblioteca de Logging (mistura o domínio do negócio com o domínio técnico).

72. Testes de unidade verificam a relação entre Authenticator e FailureReporter

73. Testes de Integração verificam a implementação do FailureReporter.