Testes Automatizados e o iOS

2,036 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,036
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
16
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • Por mais que pareça trollagem: IMHO com a mítica que ganhou o debate sobre tdd, se não faz é burro e etc... acho que se esqueceu um pouquinho do porque se faz um teste. Só por fazer? Não adianta.\n
  • Por mais que pareça trollagem: IMHO com a mítica que ganhou o debate sobre tdd, se não faz é burro e etc... acho que se esqueceu um pouquinho do porque se faz um teste. Só por fazer? Não adianta.\n
  • Um dos motivos seria aumentar as garantias de funcionamento em situações mais extremas e provavelmente não previstas no planejamento do projeto/iteração, ou seja lá qual for sua medida de tempo de trabalho para a entrega de um código funfando.\n
  • Não é impossível criar código de qualidade sem testes. Mas mais uma vez IMHO é MUITO mais fácil conseguir isso com testes. Normalmente a qualidade é o que desejamos que fique evidente, então como estabelecer se algo que está “por baixo”, como o código, tem qualidade?\n
  • \n
  • Fácil de alterar, melhorar ou adicionar feature. Código de fácil manutenção deveria ser intuitivo. Os testes podem servir como ferramenta para impedir más decisões iniciais.\n
  • Fácil de alterar, melhorar ou adicionar feature. Código de fácil manutenção deveria ser intuitivo. Os testes podem servir como ferramenta para impedir más decisões iniciais.\n
  • Fácil de alterar, melhorar ou adicionar feature. Código de fácil manutenção deveria ser intuitivo. Os testes podem servir como ferramenta para impedir más decisões iniciais.\n
  • Fácil de alterar, melhorar ou adicionar feature. Código de fácil manutenção deveria ser intuitivo. Os testes podem servir como ferramenta para impedir más decisões iniciais.\n
  • Fácil de alterar, melhorar ou adicionar feature. Código de fácil manutenção deveria ser intuitivo. Os testes podem servir como ferramenta para impedir más decisões iniciais.\n
  • Fácil de alterar, melhorar ou adicionar feature. Código de fácil manutenção deveria ser intuitivo. Os testes podem servir como ferramenta para impedir más decisões iniciais.\n
  • Difícil medir a qualidade, mas manutenabilidade é um bom indício.\n
  • Em orientação a objetos (que é de onde estou mais próximo) sei que é bem evidente essa preocupação em produzir código de qualidade. Alguns pontos que costumam ser citados: legibilidade, objetividade, alta coesão, baixo acoplamento... algumas dessas coisas são facilitadas pelos testes. “Dói” testar código que não siga essas regras. Alguma dessas práticas são possíveis unicamente se apoiadas por testes (como descrito no refactoring...)\n
  • Em orientação a objetos (que é de onde estou mais próximo) sei que é bem evidente essa preocupação em produzir código de qualidade. Alguns pontos que costumam ser citados: legibilidade, objetividade, alta coesão, baixo acoplamento... algumas dessas coisas são facilitadas pelos testes. “Dói” testar código que não siga essas regras. Alguma dessas práticas são possíveis unicamente se apoiadas por testes (como descrito no refactoring...)\n
  • Em orientação a objetos (que é de onde estou mais próximo) sei que é bem evidente essa preocupação em produzir código de qualidade. Alguns pontos que costumam ser citados: legibilidade, objetividade, alta coesão, baixo acoplamento... algumas dessas coisas são facilitadas pelos testes. “Dói” testar código que não siga essas regras. Alguma dessas práticas são possíveis unicamente se apoiadas por testes (como descrito no refactoring...)\n
  • Em orientação a objetos (que é de onde estou mais próximo) sei que é bem evidente essa preocupação em produzir código de qualidade. Alguns pontos que costumam ser citados: legibilidade, objetividade, alta coesão, baixo acoplamento... algumas dessas coisas são facilitadas pelos testes. “Dói” testar código que não siga essas regras. Alguma dessas práticas são possíveis unicamente se apoiadas por testes (como descrito no refactoring...)\n
  • Em orientação a objetos (que é de onde estou mais próximo) sei que é bem evidente essa preocupação em produzir código de qualidade. Alguns pontos que costumam ser citados: legibilidade, objetividade, alta coesão, baixo acoplamento... algumas dessas coisas são facilitadas pelos testes. “Dói” testar código que não siga essas regras. Alguma dessas práticas são possíveis unicamente se apoiadas por testes (como descrito no refactoring...)\n
  • Em orientação a objetos (que é de onde estou mais próximo) sei que é bem evidente essa preocupação em produzir código de qualidade. Alguns pontos que costumam ser citados: legibilidade, objetividade, alta coesão, baixo acoplamento... algumas dessas coisas são facilitadas pelos testes. “Dói” testar código que não siga essas regras. Alguma dessas práticas são possíveis unicamente se apoiadas por testes (como descrito no refactoring...)\n
  • Se é difícil escrever testes para código que já foi escrito de uma forma ruim. E se os testes ajudam a garantir qualidade. Pode ser uma boa ideia escrever os testes antes de existir qualquer código.\n
  • Estabelece um limite cedo: é isso que o sistema precisa fazer, se fizer, tá pronto. O tdd começa a interferir na forma como arquitetamos o sistema. Se a lâmpada acender, está pronto. Código suficiente só para que o sistema funcione, menos desenvolvimento orientado a nostradamus.\n
  • Cultura. Primeiro um teste falhando, pouco código até que ele funfe, melhorias só em código que está passando nos testes.\n
  • O que diabos é uma unidade do ponto de vista de um software?\n
  • O que diabos é uma unidade do ponto de vista de um software?\n
  • \n
  • \n
  • Onde tenta se estabelecer se o que foi feito atende. Visa os requisitos iniciais e as necessidades do usuário. \nÓtimo jeito de verificar? User stories!\n
  • User story descreve a forma como um usuário gostaria, ou usando uma palavra mais ligada ao comportamento: DEVERIA utilizar o sistema.\n
  • Mesma abordagem dos testes primeiro, mas com outro foco. Partir do que o sistema deve fazer, partir do ponto de vista do usuário por assim dizer. Dar importância para as user stories. Criar unit tests para garantir essas user stories, e só então ver a user story ok, começar de novo...\n
  • O teste precisa ser muito facilmente “repetível”, senão não faremos...\n
  • O que temos ao nosso dispor? Dentro do próprio Xcode, por padrão já tem alguma coisa bem útil...\n
  • Dentro do instruments tem o UIAutomation, javascript para manipular objetos da interface\n
  • \n
  • \n
  • É possível navegar na árvore da estrutura dos elementos na interface, e usar métodos para simular as ações do usuário.\n
  • O código é meio cru... muita coisa feita na unha.\n
  • O código é meio cru... muita coisa feita na unha.\n
  • Dá prá rodar os testes na hora, gravar os testes para rodar de novo...\n
  • Tem até os screenshots se der xabu.\nShow me the code.\n
  • Também nativo e integrado com a plataforma, existem os testes unitários\n
  • \n
  • \n
  • Basta escolher o target e rodar (command U).\nPara ver os resultados view -> navigator -> show log navigator (command 7)\n
  • Basta escolher o target e rodar (command U).\nPara ver os resultados view -> navigator -> show log navigator (command 7)\n
  • Uma classe normal (que estende SenTestCase).\n
  • Acho as assertions bem feias...\nShow me the code\n
  • Como as assertions são um pouco pobres, algumas abordagens para melhorar é apenas adicionar novas assertions...\nNão é tão troll quanto parece.\n
  • Como as assertions são um pouco pobres, algumas abordagens para melhorar é apenas adicionar novas assertions...\nNão é tão troll quanto parece.\n
  • Alguns detalhes seguindo exatamente a mesma filosofia, cria target... e assim vai. É do google deve ser bom...\n
  • Alguma semelhança com o do google? XD\nVamos ver funcionando...\n
  • Usa cucumber por baixo. Muito focado em User Stories.\n
  • Usa cucumber por baixo. Muito focado em User Stories.\n
  • Melhor visto que falado... live e dá prá fazer query nos elementos...\n
  • Configura o projeto, tem que duplicar o target, é a própria aplicação que vai rodar mesmo (cucumber).\n
  • Configura o projeto, tem que duplicar o target, é a própria aplicação que vai rodar mesmo (cucumber).\n
  • Configura o projeto, tem que duplicar o target, é a própria aplicação que vai rodar mesmo (cucumber).\n
  • Configura o projeto, tem que duplicar o target, é a própria aplicação que vai rodar mesmo (cucumber).\n
  • \n
  • Testes Automatizados e o iOS

    1. 1. Testes Automatizados e o iOS algumas ferramentas e opiniões
    2. 2. é quem?• Ricardo Valeriano•• @sr_valeriano• github.com/ricardovaleriano
    3. 3. é como?• É feia• Não é um talk extremamente técnico• Deixa isso pro @dchohfi• Mas assume que você já usa o Xcode...
    4. 4. é como?• É feia• Não é um talk extremamente técnico• Deixa isso pro @dchohfi• Mas assume que você já usa o Xcode...
    5. 5. é como?• É feia• Não é um talk extremamente técnico• Deixa isso pro @dchohfi• Mas assume que você já usa o Xcode...
    6. 6. Porque testar?
    7. 7. Porque testar?Para ter certeza de que está funcionando.
    8. 8. Previsibilidade
    9. 9. Previsibilidade
    10. 10. Qualidade
    11. 11. CUIDADO:proximidade de slide clichê detectada
    12. 12. Manutenabilidade
    13. 13. Manutenabilidade
    14. 14. Manutenabilidade
    15. 15. Qualidade
    16. 16. Qualidade
    17. 17. Test Driven Development
    18. 18. Test Driven Development
    19. 19. Test Driven Design
    20. 20. Red Green Refactor
    21. 21. Teste Unitário
    22. 22. Teste UnitárioAquele que testa uma unidade
    23. 23. Teste Unitário• Testa em isolamento• Independente de interações• (Mocks, Stubs e relacionados)
    24. 24. Teste Integração• Interação entre unidades• “Componentes” maiores e testados surgem
    25. 25. Teste de Aceitação
    26. 26. Teste de Aceitação
    27. 27. Behavior Driven Development
    28. 28. Automação
    29. 29. The Apple Way
    30. 30. Aceitação (user stories)
    31. 31. Opalhes :)• Roda no dispositivo (e no simulador)• Integrado com a IDE• É só JavaScript• Vai bem com Jasmine
    32. 32. aaaahh :(• É JavaScript• Não é Open Source
    33. 33. Como funfa?
    34. 34. Tapping!var target = UIATarget.localTarget();var app = target.frontMostApp();var window = app.mainWindow();var button = window.buttons()[0];button.tap();target.tap({x:100, y:200});
    35. 35. LogFail? LogPass?var target = UIATarget.localTarget();UIALogger.logStart("go to original position");target.tap({x:100, y:200});if (field.rect()["origin"]["y"] == position)! UIALogger.logPass("ok");else! UIALogger.logFail("Nok");
    36. 36. Rodando os Testes
    37. 37. Relatório
    38. 38. Testes Unitários
    39. 39. Opalhes :)• Roda no dispositivo (e no simulador)• Integrado com a IDE• Objective-C
    40. 40. aaaahh :(• Marcos (STAssertTrue)• Cru (nada de mocks ou afins)• Objective-C
    41. 41. Testes Unitários
    42. 42. Testes Unitários
    43. 43. Testes Unitários
    44. 44. Just Code#import "RTZTranslator_tests.h"#import "RTZTranslator.h"@interface RTZTranslator_tests() {@private RTZTranslator *translator;}@end@implementation RTZTranslator_tests- (void)setUp{ [super setUp]; translator = [[RTZTranslator alloc] init];
    45. 45. STAssert...?- (void)testNossaToCacildis{ NSString *translation = [translatortranslateFrom:@"nossa, nossa, assim..."]; BOOL isEqual = [translationisEqualToString:@"cacildis, cacildis, assim..."]; STAssertTrue(isEqual, @"nossa test");}
    46. 46. Abordagensalternativas?
    47. 47. Abordagens alternativas? Simplesmente adicionar mais assertions...XPTOAssertEqualStrings(str1, str2, “há! há! salci fufu”)
    48. 48. Google Toolbox for Mac• Sem .h• STAssertEqualStrings• STAssertNotEqualString• Keychain Testing• Testes de UI
    49. 49. Google Toolbox for Mac iPhoneUnitTesting• Sem .h• STAssertEqualStrings• STAssertNotEqualString• Keychain Testing• Testes de UI
    50. 50. GHUnit• Sem .h• GHAssertEqualStrings• GHAssertNotEqualString• Testes de UI• (IMHO) Bem documentado
    51. 51. GHUnit Objective-C (OSX e iOS)• Sem .h• GHAssertEqualStrings• GHAssertNotEqualString• Testes de UI• (IMHO) Bem documentado
    52. 52. FrankFeature: Login to the appScenario: Successful login Given I launch the app When I log in with a valid userid and password Then I am on the start view
    53. 53. Frank CucumberFeature: Login to the appScenario: Successful login Given I launch the app When I log in with a valid userid and password Then I am on the start view
    54. 54. FrankWhen /^I use the keyboard to fill in the textfield marked "([^"]*)" with "([^"]*)"$/ do |text_field_mark,text_to_type| text_field_selector = "view marked:#{text_field_mark}" check_element_exists( text_field_selector ) touch( text_field_selector ) frankly_map( text_field_selector, setText:, text_to_type ) frankly_map( text_field_selector, endEditing:, true )end
    55. 55. Frank (setps) RubyWhen /^I use the keyboard to fill in the textfield marked "([^"]*)" with "([^"]*)"$/ do |text_field_mark,text_to_type| text_field_selector = "view marked:#{text_field_mark}" check_element_exists( text_field_selector ) touch( text_field_selector ) frankly_map( text_field_selector, setText:, text_to_type ) frankly_map( text_field_selector, endEditing:, true )end
    56. 56. Frank
    57. 57. FrankSymbiote
    58. 58. Frank
    59. 59. FrankiOS (server x client)
    60. 60. Obrigadis!• @sr_valeriano• github.com/ricardovaleriano

    ×