Xamarin Forms Unit Testing

Tive a mesma pergunta durante algum tempo e finalmente decidi-me por uma estratégia que tem duas partes que consistem em testes unitários do código e depois testes UI.

A unidade testa o código que não tem IU. Por exemplo, testes para o modelo, serviços, etc. Normalmente eu tenho um projeto de teste de unidade e os testes de unidade são escritos contra a biblioteca compartilhada.

Os testes IU são específicos do so. Tenho um projecto de teste iOS e um projecto de Teste Android. Pensei em ter uma única UI. projecto de teste que seria o Nirvana. Eu só não acredito que ele poderia lidar com todas as nuances UI de cada so.

Durante a construção, faço os testes de unidade. Se passarem, os testes da IU são executados. Tenho dois conjuntos de testes, testes de fumo e testes profundos, para cada so. Os testes de fumaça são feitos em um pequeno subconjunto de dispositivos. Eu posso julgar rapidamente a qualidade de uma construção antes de perder tempo de teste em más construções. Em seguida, em boas construções, os testes profundos são realizados no mesmo pequeno subconjunto de dispositivos. Se tudo passa, então os testes de fumaça são realizados em um conjunto maior de dispositivos. Se os relatórios de colisão aparecerem num dispositivo na piscina grande, então os testes profundos são realizados. Se o dispositivo em questão tem uma base de Usuários grande o suficiente e continua a ser problemático, ele é adicionado ao teste de pool profundo. ([1]}aprendi no trabalho ao longo de uma carreira muito longa, incluindo 7 anos a trabalhar na Microsoft, incluindo ser PM em algumas equipas que trabalham no Framework. NET, Framework SDK e afins. tecnologias como ASP.NET MVC, WebAPI, Azure, etc. O processo de compilação que eu descrevi acima, é vagamente baseado em como o Framework. NET e o Framework SDK Framework. net usam para ser construídos. A construção do. NET demora um pouco. O teste é ainda mais longo (pense dias físicos) por isso ter um teste rápido de fumaça como parte da construção foi muito útil e economia de tempo. Algumas vezes a compilação iria compilar e produzir instalações, mas teria problemas que alguns (relativamente falando) testes poderiam apontar para uma má compilação e salvar lotes de está na hora das equipas de perguntas e Respostas.

Rookiejava abaixo adicionou alguns bons links para aprender a escrever testes.

O meu melhor conselho para desenhar testes é ser estúpido, mau, rigoroso e um gremlin. Por estúpido fazer testes que apenas fazem coisas que ninguém que entende programar faria. O melhor exemplo disso foi um bug de login encontrado na x-box. O filho de alguém fez uma coisa muito estranha e, de repente, entrou na conta do Pai. Por ser mau, quero dizer que faz coisas loucas que tu ... ia deixar-te zangado. Trocadilho. Por exemplo, batendo em seu produto. Não me digas que há um grande fabricante seguro que bater no cofre num determinado lugar permite-te abri-lo sem o código! Literalmente ser rigoroso e não fazer suposições. Se o caso de uso, história de usuário ou que documento você usa para saber como o código é suposto funcionar diz fatique, então seu teste deve deixar o código passar apenas no fatique, mesmo que todos sabemos que deve ser fadiga. Ficheiro um erro contra a utilização case / user story;) o maior conselho que posso dar é pensar como um gremlin. Não basta testar que o caminho feliz funciona ou regras de validação de dados funcionam. Test for doing bizarre outrageous inputs and combination of commands, key presses etc. A melhor ferramenta de teste que eu usei foi uma ferramenta de teste Microsoft para Windows Mobile. Sim, As Janelas. A ferramenta faria coisas completamente aleatórias para a UI de um aplicativo. As teclas aleatórias colocam informação de baixo para cima ou mesmo em ordens aleatórias, entre outras coisas. Ele foi divertido ver quantos inconscientemente fizeram suposições que eu e outros fizemos. Ele até encontrou um bug que poderia permitir a alguém acesso completo a um dispositivo em que eu estava trabalhando para uma agência do governo que não só nossa equipe falhou, mas outros testadores de segurança externos falharam. Remendámo-lo discretamente antes do dispositivo ir a alguém fora do desenvolvimento.

Por favor veja abaixo links

• Teste de unidade para Xamarin.Formulários (plataforma cruzada)
  : Veja também o vídeo clipe sobre a criação de testes unitários para aplicações dos formulários Xamarin
• teste de unidade para Xamarin.iOS

P. S.

Xamarina.A aplicação formulários é geralmente definida em um projeto compartilhado entre plataformas (uma biblioteca de classe portátil ou um projeto compartilhado) e combinado com projetos específicos de plataformas. Xamarina.Os formulários são melhor para:

• aplicações que requerem pouca funcionalidade específica da plataforma onde
• A partilha de códigos é mais importante do que a interface personalizada
• Os programadores sentem-se confortáveis com o XAML

Xamarina.iOS & Xamarin.Android são melhores para:

• aplicativos com interações que requerem comportamento nativo
• aplicações que usam muitas APIs específicas da plataforma
• aplicações em que a interface personalizada é mais importante do que a partilha de códigos

Esta ligação também explicou a diferenciação entre Xamarina.Formulários e Xamarin.Nativo.