48. Google Toolbox for Mac
• Sem .h
• STAssertEqualStrings
• STAssertNotEqualString
• Keychain Testing
• Testes de UI
49. Google Toolbox for Mac
iPhoneUnitTesting
• Sem .h
• STAssertEqualStrings
• STAssertNotEqualString
• Keychain Testing
• Testes de UI
50. GHUnit
• Sem .h
• GHAssertEqualStrings
• GHAssertNotEqualString
• Testes de UI
• (IMHO) Bem documentado
51. GHUnit
Objective-C (OSX e iOS)
• Sem .h
• GHAssertEqualStrings
• GHAssertNotEqualString
• Testes de UI
• (IMHO) Bem documentado
52. 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
53. 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
54. 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
55. 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
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