SlideShare uma empresa Scribd logo
1 de 60
Testes Automatizados
       e o iOS
   algumas ferramentas e opiniões
é quem?

•   Ricardo Valeriano
•
•   @sr_valeriano
•   github.com/ricardovaleriano
é como?
•   É feia


•   Não é um talk extremamente técnico


•   Deixa isso pro @dchohfi


•   Mas assume que você já usa o Xcode...
é como?
•   É feia


•   Não é um talk extremamente técnico


•   Deixa isso pro @dchohfi


•   Mas assume que você já usa o Xcode...
é como?
•   É feia


•   Não é um talk extremamente técnico


•   Deixa isso pro @dchohfi


•   Mas assume que você já usa o Xcode...
Porque testar?
Porque testar?
Para ter certeza de que está funcionando.
Previsibilidade
Previsibilidade
Qualidade
CUIDADO:

proximidade de slide
       clichê
     detectada
Manutenabilidade
Manutenabilidade
Manutenabilidade
Qualidade
Qualidade
Test Driven Development
Test Driven Development
Test Driven Design
Red Green Refactor
Teste Unitário
Teste Unitário
Aquele que testa uma unidade
Teste Unitário


•   Testa em isolamento
•   Independente de interações
•   (Mocks, Stubs e relacionados)
Teste Integração


•   Interação entre unidades
•   “Componentes” maiores e testados surgem
Teste de Aceitação
Teste de Aceitação
Behavior Driven Development
Automação
The Apple Way
Aceitação (user stories)
Opalhes :)

•   Roda no dispositivo (e no simulador)
•   Integrado com a IDE
•   É só JavaScript
•   Vai bem com Jasmine
aaaahh :(


•   É JavaScript
•   Não é Open Source
Como funfa?
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});
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");
Rodando os Testes
Relatório
Testes Unitários
Opalhes :)


•   Roda no dispositivo (e no simulador)
•   Integrado com a IDE
•   Objective-C
aaaahh :(


•   Marcos (STAssertTrue)
•   Cru (nada de mocks ou afins)
•   Objective-C
Testes Unitários
Testes Unitários
Testes Unitários
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];
STAssert...?

- (void)testNossaToCacildis
{
    NSString *translation = [translator
translateFrom:@"nossa, nossa, assim..."];

    BOOL isEqual = [translation
isEqualToString:@"cacildis, cacildis, assim..."];

    STAssertTrue(isEqual,         @"nossa test");
}
Abordagens
alternativas?
Abordagens
               alternativas?
    Simplesmente adicionar mais assertions...
XPTOAssertEqualStrings(str1, str2, “há! há! salci fufu”)
Google Toolbox for Mac

•   Sem .h
•   STAssertEqualStrings
•   STAssertNotEqualString
•   Keychain Testing
•   Testes de UI
Google Toolbox for Mac
              iPhoneUnitTesting

•   Sem .h
•   STAssertEqualStrings
•   STAssertNotEqualString
•   Keychain Testing
•   Testes de UI
GHUnit

•   Sem .h
•   GHAssertEqualStrings
•   GHAssertNotEqualString
•   Testes de UI
•   (IMHO) Bem documentado
GHUnit
          Objective-C (OSX e iOS)

•   Sem .h
•   GHAssertEqualStrings
•   GHAssertNotEqualString
•   Testes de UI
•   (IMHO) Bem documentado
Frank
Feature: Login to the app
Scenario: Successful login
  Given I launch the app
  When I log in with a valid userid and password
  Then I am on the start view
Frank
                    Cucumber

Feature: Login to the app
Scenario: Successful login
  Given I launch the app
  When I log in with a valid userid and password
  Then I am on the start view
Frank

When /^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
Frank
                         (setps) Ruby

When /^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
Frank
Frank
Symbiote
Frank
Frank
iOS (server x client)
Obrigadis!


•   @sr_valeriano
•   github.com/ricardovaleriano

Mais conteúdo relacionado

Semelhante a Automated iOS testing tools and opinions

Android: testes automatizados e TDD
Android: testes automatizados e TDDAndroid: testes automatizados e TDD
Android: testes automatizados e TDDDextra
 
One Language to Rule Them All: TypeScript
One Language to Rule Them All: TypeScriptOne Language to Rule Them All: TypeScript
One Language to Rule Them All: TypeScriptLoiane Groner
 
Swift, a nova linguagem de programação da Apple (CocoaHeads Sao Paulo)
Swift, a nova linguagem de programação da Apple (CocoaHeads Sao Paulo)Swift, a nova linguagem de programação da Apple (CocoaHeads Sao Paulo)
Swift, a nova linguagem de programação da Apple (CocoaHeads Sao Paulo)Juliana Chahoud
 
TypeScript - Campus party 2013
TypeScript - Campus party 2013TypeScript - Campus party 2013
TypeScript - Campus party 2013Giovanni Bassi
 
Programação "Estruturada" com Java
Programação "Estruturada" com JavaProgramação "Estruturada" com Java
Programação "Estruturada" com JavaLuiz Ricardo Silva
 
Curso: Desenvolvimento de aplicativos híbridos (dia 2)
Curso: Desenvolvimento de aplicativos híbridos (dia 2)Curso: Desenvolvimento de aplicativos híbridos (dia 2)
Curso: Desenvolvimento de aplicativos híbridos (dia 2)Wennder Santos
 
Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...
Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...
Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...minastestingconference
 
WTF Javascript - FrontInRio 2011
WTF Javascript - FrontInRio 2011WTF Javascript - FrontInRio 2011
WTF Javascript - FrontInRio 2011Leonardo Balter
 
Não deixe para testar depois o que você pode testar antes.
Não deixe para testar depois o que você pode testar antes. Não deixe para testar depois o que você pode testar antes.
Não deixe para testar depois o que você pode testar antes. Tchelinux
 
Importância de Testes Automatizados para Continuous Delivery & DevOps
Importância de Testes Automatizados para Continuous Delivery & DevOpsImportância de Testes Automatizados para Continuous Delivery & DevOps
Importância de Testes Automatizados para Continuous Delivery & DevOpsSamanta Cicilia
 
A primeira app iOS (a gente não esquece)
A primeira app iOS (a gente não esquece)A primeira app iOS (a gente não esquece)
A primeira app iOS (a gente não esquece)Ricardo Valeriano
 
TDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no AndroidTDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no Androidtdc-globalcode
 
TDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no AndroidTDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no Androidtdc-globalcode
 

Semelhante a Automated iOS testing tools and opinions (20)

Android: testes automatizados e TDD
Android: testes automatizados e TDDAndroid: testes automatizados e TDD
Android: testes automatizados e TDD
 
One Language to Rule Them All: TypeScript
One Language to Rule Them All: TypeScriptOne Language to Rule Them All: TypeScript
One Language to Rule Them All: TypeScript
 
Testing sucks
Testing sucksTesting sucks
Testing sucks
 
Desenvolvimento iOS
Desenvolvimento iOSDesenvolvimento iOS
Desenvolvimento iOS
 
Robotium_Sikuli
Robotium_SikuliRobotium_Sikuli
Robotium_Sikuli
 
Swift, a nova linguagem de programação da Apple (CocoaHeads Sao Paulo)
Swift, a nova linguagem de programação da Apple (CocoaHeads Sao Paulo)Swift, a nova linguagem de programação da Apple (CocoaHeads Sao Paulo)
Swift, a nova linguagem de programação da Apple (CocoaHeads Sao Paulo)
 
TypeScript - Campus party 2013
TypeScript - Campus party 2013TypeScript - Campus party 2013
TypeScript - Campus party 2013
 
JavaScript - A Linguagem
JavaScript - A LinguagemJavaScript - A Linguagem
JavaScript - A Linguagem
 
Programação "Estruturada" com Java
Programação "Estruturada" com JavaProgramação "Estruturada" com Java
Programação "Estruturada" com Java
 
Curso: Desenvolvimento de aplicativos híbridos (dia 2)
Curso: Desenvolvimento de aplicativos híbridos (dia 2)Curso: Desenvolvimento de aplicativos híbridos (dia 2)
Curso: Desenvolvimento de aplicativos híbridos (dia 2)
 
Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...
Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...
Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...
 
WTF Javascript - FrontInRio 2011
WTF Javascript - FrontInRio 2011WTF Javascript - FrontInRio 2011
WTF Javascript - FrontInRio 2011
 
Não deixe para testar depois o que você pode testar antes.
Não deixe para testar depois o que você pode testar antes. Não deixe para testar depois o que você pode testar antes.
Não deixe para testar depois o que você pode testar antes.
 
Importância de Testes Automatizados para Continuous Delivery & DevOps
Importância de Testes Automatizados para Continuous Delivery & DevOpsImportância de Testes Automatizados para Continuous Delivery & DevOps
Importância de Testes Automatizados para Continuous Delivery & DevOps
 
Java script aula 02 - operadores
Java script   aula 02 - operadoresJava script   aula 02 - operadores
Java script aula 02 - operadores
 
A primeira app iOS (a gente não esquece)
A primeira app iOS (a gente não esquece)A primeira app iOS (a gente não esquece)
A primeira app iOS (a gente não esquece)
 
Sua primeira app iOS
 Sua primeira app iOS Sua primeira app iOS
Sua primeira app iOS
 
Introdução ao Java 5
Introdução ao Java 5Introdução ao Java 5
Introdução ao Java 5
 
TDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no AndroidTDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no Android
 
TDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no AndroidTDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no Android
 

Automated iOS testing tools and opinions

Notas do Editor

  1. \n
  2. \n
  3. \n
  4. \n
  5. 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
  6. 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
  7. 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
  8. 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
  9. \n
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. Difícil medir a qualidade, mas manutenabilidade é um bom indício.\n
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. Cultura. Primeiro um teste falhando, pouco código até que ele funfe, melhorias só em código que está passando nos testes.\n
  26. O que diabos é uma unidade do ponto de vista de um software?\n
  27. O que diabos é uma unidade do ponto de vista de um software?\n
  28. \n
  29. \n
  30. 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
  31. User story descreve a forma como um usuário gostaria, ou usando uma palavra mais ligada ao comportamento: DEVERIA utilizar o sistema.\n
  32. 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
  33. O teste precisa ser muito facilmente “repetível”, senão não faremos...\n
  34. O que temos ao nosso dispor? Dentro do próprio Xcode, por padrão já tem alguma coisa bem útil...\n
  35. Dentro do instruments tem o UIAutomation, javascript para manipular objetos da interface\n
  36. \n
  37. \n
  38. É possível navegar na árvore da estrutura dos elementos na interface, e usar métodos para simular as ações do usuário.\n
  39. O código é meio cru... muita coisa feita na unha.\n
  40. O código é meio cru... muita coisa feita na unha.\n
  41. Dá prá rodar os testes na hora, gravar os testes para rodar de novo...\n
  42. Tem até os screenshots se der xabu.\nShow me the code.\n
  43. Também nativo e integrado com a plataforma, existem os testes unitários\n
  44. \n
  45. \n
  46. Basta escolher o target e rodar (command U).\nPara ver os resultados view -> navigator -> show log navigator (command 7)\n
  47. Basta escolher o target e rodar (command U).\nPara ver os resultados view -> navigator -> show log navigator (command 7)\n
  48. Uma classe normal (que estende SenTestCase).\n
  49. Acho as assertions bem feias...\nShow me the code\n
  50. Como as assertions são um pouco pobres, algumas abordagens para melhorar é apenas adicionar novas assertions...\nNão é tão troll quanto parece.\n
  51. Como as assertions são um pouco pobres, algumas abordagens para melhorar é apenas adicionar novas assertions...\nNão é tão troll quanto parece.\n
  52. Alguns detalhes seguindo exatamente a mesma filosofia, cria target... e assim vai. É do google deve ser bom...\n
  53. Alguma semelhança com o do google? XD\nVamos ver funcionando...\n
  54. Usa cucumber por baixo. Muito focado em User Stories.\n
  55. Usa cucumber por baixo. Muito focado em User Stories.\n
  56. Melhor visto que falado... live e dá prá fazer query nos elementos...\n
  57. Configura o projeto, tem que duplicar o target, é a própria aplicação que vai rodar mesmo (cucumber).\n
  58. Configura o projeto, tem que duplicar o target, é a própria aplicação que vai rodar mesmo (cucumber).\n
  59. Configura o projeto, tem que duplicar o target, é a própria aplicação que vai rodar mesmo (cucumber).\n
  60. Configura o projeto, tem que duplicar o target, é a própria aplicação que vai rodar mesmo (cucumber).\n
  61. \n