Nosso TGIF hoje vai falar sobre o novo produto do google e lancar uma pergunta no ar.
Semana passada o google lançou mais um produto para o mercado, ou melhor vai lançar no dia 9 de setembro, o Google Fiber.
Google Fiber é nada menos que uma proposta da google de oferecer um serviço de internet cabeada com 1Gb de upload e download. Se você tem em casa uma internet de 10, 15 ou ate 100Mb e acha que está bombando. Aguarde que é por muito pouco tempo 🙂
A google promete revolucionar a internet e vai iniciar esse serviço pioneiro no mercado com precos realmente agressivos:
Conexão de 1Gb + TV por U$ 120 sem taxa de instalação.
Conexão de 1Gb por U$ 70 sem taxa de instalação.
Conexão de 5 Mb apenas pagando a taxa de instalação (U$300) ou 12 meses de U$ 25 e garantia de 7 anos sem pagar.
A pergunta que fica é: Se você estiver com esse serviço google fiber e fora isso ainda usar os produtos do google com o Google Drive , Google Talk, etc… e acontecer algo parecido com o que aconteceu no dia do lançamento do produto para a maioria dos usuários do Google Talk que passou parte da manhã sem conseguir usá-lo (Veja imagem abaixo)
Clique para ampliar
Seria o caos nas nossas vidas ? O problema da semana passada eu acho que não foi muito grave pois tivemos várias outras formas de nos comunicar pela web: skype, facebook, msn ate mesmo pelo whatsapp.
Agora imaginem uma dependência física como o Google Fiber, onde possivelmente vai sair na frente e ter muita gente usando por ai.
Se der um tango down ? e ai ? Será que vai ter muita gente pulando pela janela ?
Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.
TMM, se você conhece os termo CMM então não terá nenhuma dificuldade de entender o que é TMM, pois o objetivo do TMM é ser usado de uma maneira semelhante ao CMM(Capability Maturity Model), no qual foi baseado, que é o de proporcionar uma estrutura para avaliar a maturidade dos processos de teste em uma organização, e assim definindo alvos na melhoria da maturidade destes processos. O TMM é o acrônimo Test Maturity Model e foi primeiramente desenvolvido pela Dr. Ilene Burnstein do Instituto de Tecnologia de Illinois. O TMM pode ser usado tanto em conjunto com o CMM como também pode ser usado sozinho.
Assim como o CMM, o TMM possui 5 niveis de maturidade do processo.
1 – Inicial, que significa que a organização esta usando métodos ad-hoc para testes, usualmente não existe um profissional qualificado e nem ferramentas especializadas para testes e basicamente o objetivo dos testes é mostrar que o sistema e software funcionam.
2 – Fase de definição, neste segundo nível os testes já são considerados como processo, o mesmo eh definido como uma fase após o desenvolvimento e já é usado algumas técnicas básicas de testes. Nesta fase o objetivo dos testes são verificar que o sistema e software estão de acordo com os requisitos.
3 – Integração, como o nome da sugere o processo de teste é integrado ao ciclo de vida do desenvolvimento do software. Nesta fase já podem ser vistos treinamentos formais de técnicas de testes, controle e monitoramento do processo de teste e o inicio do uso de ferramentas de automação. Um bom exemplo de integração dos processos de testes com o ciclo de vida do desenvolvimento de software é o conhecido Modelo-V
4 – Gerenciado e mensurado, nesta fase a organização já passa a controlar e gerenciar o processo de teste de maneira ainda mais formal, utilizando quantificações capturadas através de métricas bem definidas. O desenvolvimento do produto passa a ser testado em busca de atributos de qualidade como confiabilidade, usabilidade e manutenibilidade. O casos de teste são armazenados em bancos de dados de ferramentas de gerenciamento de testes, assim como os defeitos que são registrados em uma ferramenta com seu devido grau de severidade e prioridade.
5 – Otimização, nesta fase o teste passa a ser institucionalizado dentro da organização, o processo de teste eh muito bem definido, assim como seus custos e efetividade são monitorados e a automação dos teste são um das partes principais do processo.
Ah, lembre-se que você pode ver por ai como TPI (Test Process Improvement), ou TMMi (Test Maturity Model Integration) nao sao a mesma coisa apesar de terem praticamente o mesmo objetivo, existem algumas diferenças entre eles e para saber mais detalhes leiam este documento bem intuitivo e escrito por Emerson Rios e Ricado Cristalli ou então beba a água direto da fonte (TPI, TMMi)
Então após essa breve explicação sobre TMM, você consegue ter uma ideia em qual nível TMM da sua empresa ?
Recentemente participei do IV EBTS, no qual participei como palestrante e com certeza, o tema mais falado neste evento foi cloud computing. Inclusive o palestrante mais aguardado do evento Profº Silvio Meira falou sobre este assunto e alertou que todos se preocupassem em se atualizar sobre o assunto na área de testes. Neste evento participei de um minicurso sobre Cloud Computing e o ministrante e meu amigo Elias Queiroga , abriu minha mente para essa área e me deixou bastante empolgado com os desafios que quero compartilhar com vocês.
Antes de falarmos sobre testes em sistemas na nuvem, precisamos entender alguns conceitos básicos sobre a mesma, e a primeira delas são os tipos de cloud que existem hoje e os principais tipo são IaaS (Infra-estrutura como serviço), PaaS (Plataforma com serviço) e SaaS (Software como serviço).
No IaaS utilizamos puramente a infra do servidor para a nossa necessidade, como exemplo armazenamento ou memória e processamento. Já no PaaS utlizamos alguma plataforma configurada no servidor, podemos citar diversos exemplos como Google App Engine, Windows Azure, etc. Por último temos o SaaS que simplesmente é o software em si que usamos na nuvem e não faltam exemplos como Google Docs, iCloud, Microsoft SharePoint Online, etc.
Algumas das características mais importantes na computação em nuvem são: segurança, performance, disponibilidade e escalabilidade. Notem que estas características não são tão triviais de serem testadas e precisam do suporte de ferramentas específicas, muitas delas até a infra-estrutura de hardware precisa ser investida para viabilizar os testes de alguns sistemas na nuvem.
Figura 01
Um exemplo claro que podemos dar de como testar um sistema na cloud é utilizando ferramentas como JMeter que simula o múltiplo acesso a um serviço na cloud. Como isso funciona ? A aplicação quando instalada e configurada para rodar numa única máquina, abre várias threads para acessar o sistema alvo de teste e validar a sua capacidade de atender as requisições (Figura 1). Caso o sistema falhe antes de atender a quantidade de requisições previamente definida, ai os desenvolvedores do sistema tem que prover alguma solução e provavelmente será a replicação do sistema internamente na nuvem e a inserção de um balanceador para direcionar as requisições para cada instância da aplicação, como mostra a figura 2.
Figura 02
E quando o sistema em teste tem como requisito uma capacidade de atender à uma quantidade de requisições maior do que a nossa máquina de teste é capaz de gerar ? Ai vem o caso no qual precisamos inverstir na infra-estrutura de hardware do nosso ambiente de teste para viabilizar a validação desse sistema na nuvem. Nesse caso podemos colocar mais máquinas no nosso ambiente de teste e configurar o Jmeter para gerenciar a geração de requisições paralelas por estas novas máquinas, com isso aumentamos a capacidade do nosso ambiente de teste para testar o sistema na nuvem. A figura 3 mostra uma máquina “chefe” que gerencia as requisições que são feitas por cada máquina “escrava”, e cada uma dessas máquinas por sua vez abre várias threads para gerar requisições ao sistema na nuvem.
Figura 03
Esse é apenas um exemplo de uma das características de um sistema na nuvem pode ser testada, existem diversas outras ferramentas com diferentes propósitos para validade esses sistemas. Para saber mais sobre computação na nuvem visite este site developerworks da IBM e para se aprofundar em teste para computação na nuvem, este tópico sobre cloud testing na wiki é bastante relevante .
Todos perceberam que o que se fala nos últimos dias foi o lançamento do Google Drive, e como a maioria dos produtos que a google lança causa um rebuliço nos concorrentes, a Microsoft por exemplo reorganizou seu serviço chamado Skydrive. Mas não estamos aqui para falar sobre essas novidades, até porque todo mundo já esta sabendo e se não sabe pergunte ao sei amigo nerd.
Estamos aqui para resumir quais serviços mais conhecidos no mundo de armazenamento da nuvem e detalhes de cada um deles inclusive com a média de preço. Sem mais delongas, vocês podem conferir a tabela que criamos abaixo.
O melhor custo benefício pode variar de pessoa para pessoa. Por exemplo, para um usuário que trabalha com arquivos muito grandes não vale a pena contratar o serviço da Box mesmo ela possuindo o preço mais barato por GB. Então analise a nossa tabela e escolha a melhor opção para você.
Leia, também, outros artigos já publicados na série:A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.
Olá pessoal, estou de volta pra mais post da série. No último post falamos como implementar um teste automático para verificar a nossa aplicação calculadora fajuta usando as classes que a API do android nos fornece que é principalmente a a classe ActivityInstrumentationTestCase2 . E agora vamos dar um exemplo do mesmo teste automático utilizando o robotium e vamos ver a diferença e o quão prático fica implementar um teste utilizando este framework de teste, principalmente quando usamos uma aplicação com mais de uma activity ou quando não temos acesso ao código fonte da mesma.
Primeiramente vamos baixar o arquivo .jar no site do robotium neste link. A versão que estou usando é a mais recente robotium-solo-3.1.jar. Vamos criar o projeto de teste da mesma forma que criamos o projeto de teste do post anterior. Depois clicamos com o botão direito em cima do projeto e vamos na propriedade do mesmo. Na nova janela selecionamos Java Build Path e na aba Libraries adicionamos o jar que acabamos de baixar no projeto através do botão Add External JARs…
Depois apenas criamos a classe de teste da mesma forma que criamos no projeto anterior, ou seja, fazendo com que esta classe estenda de ActivityInstrumentationTestCase2 e no seu construtor também chamamos o super passando por parâmetro o pacote e a class da activity principal do projeto que vamos testar, no nosso caso “br.cesar.edu” e CalculatorActivity.class. A mudança em relação a projeto anterior começa a partir de agora. Primeiro criamos um atributo da classe do tipo Solo que é um classe que o framework Robotium nos prover e com esta classe nós praticamente resolvemos tudo no nossos testes. Depois vamos para os metodos setUp() e tearDown(), no qual respectivamente inicializamos e finalizamos este atributo para garantir que o teste vai ser rodado corretamente. E o código fica assim:
public class TestMain extends ActivityInstrumentationTestCase2<CalculatorActivity>{
private Solo solo;
public TestMain() {
super(“br.edu.cesar”, CalculatorActivity.class);
}
protected void setUp() throws Exception {
super.setUp();
solo = new Solo(getInstrumentation(), getActivity());
}
Pronto, a partir deste momente estamos praticamente com 90% do projeto de teste finalizado. Agora vamos apenas para a implementação do teste em si. Se observarem o código do projeto de teste anterior já podemos perceber o quanto de código deixamos de escrever no método setUp(). Antes tínhamos que pegar a instâncias de todos os views que iríamos interagir no teste, além de ter que criar um Monitor para monitorar a próxima tela que iria exibir o resultado da operação. No caso do projeto usando o robotium, não precisamos nos preocupar com isso, apenas deixamos que a classe Solo se encarrega de pegar as instâncias dos view e interagir com eles.
Vamos reproduzir os mesmo dois testes que criamos no projeto anterior da mesma forma que é criando os métodos começando com a string test na frente do nome do mesmo. No primeiro teste vamos passar os valores 2 e 8 e esperemos que o resultado da soma seja 10 e no segundo teste vamos passar o valores 2 e 81 e vamos esperar que o valor da soma seja um erro “Número Inválido”. O código dos teste vai simples assim :
Apenas pegamos a intância de solo e usamos o métodos triviais como enterText no qual passamos o index do componente, no nosso caso para o primeiro editText é o valor 0 e o segundo editText o valor do indice é 1, e no segundo parâmetro e passamos o texto em si , no nosso projeto seria os números a serem somados. Não podemos esquecer que nesta aplicação o resultado aparece numa nova tela e para que o teste seja finalizado precisamos voltar para a tela inicial para que o próximo teste seja executado a partir daquela tela inicial e por isso chamamos o método goBack().
Bem pessoal, basicamente é isso que temos que ver em relação a automação de testes para aplicações Android e aqui neste link vocês podem baixar o código do nosso projeto de teste utilizando o robotium. Não adicionarei o vídeo de dos testes rodando pois visualmente o teste roda da mesma forma como o projeto de teste anterior roda, apenas o código é mais simples.
Ahh, antes que eu me esqueca, se você tiverem apenas o arquivo .apk de alguma aplicação Android, lembre-se que com o robotium também é possível testa-lo, pois como podem perceber não precisamos ter conhecimento detalhado do código da aplicação que vamos testar, apenas precisamos saber quais as view que esta aplicação tem em cada tela e ter uma noção prévia da navegação das telas dessa aplicação. Para ser sincero ainda não fiz nenhum teste utilizando apenas o apk de uma aplicação. Por isso não vou detalhar como se faz aqui. Apenas posso passar o link do tutorial e prometer que no futuro volto a postar algo relacionado a este processo. Abraços e até a próxima.
Estamos de volta em mais um post da série de como automatizar testes para aplicações em Android. E agora vamos para a parte que mais interessa à todos que é como automatizar testes para aplicações Android.
No eclipse vamos em File-> New -> Other e dentro da tela de New, selecionamos a opção Android Test Project e clicamos em Next (Passo 1 da imagem). Colocamos um nome no projeto de teste, por recomendação o nome do testes geralmente é o nome do projeto a ser testado concatenado com a palavra “Test”, no nosso caso o projeto a ser testado se chama Calculadora então o nome do projeto de teste será CalculadoraTest (Passo 2 da imagem) , colocando o nome do projeto então clicamos em Next. O nosso terceiro passo para criação do projeto de teste é selecionar o projeto que será testado, no nosso caso será Calculadora (Passo 3 da imagem) e clicamos em Finish. No final o eclipse criou um projeto de teste com boa parte já configurada como podemos observar no ultimo passo da imagem abaixo, onde percebemos que o projeto de teste foi criado com o pacote quase igual ao projeto que vai ser testado, exceto pela adição de um novo pacote chamado test.
Clique na imagem para ampliar
Em um projeto de teste para android podemos definir diversos objetivos e criar diversas classes de teste, no post atual a classe que estamos criando tem o objetivo de testar as funcionalidades básicas da calculadora utilizando a interface da mesma. Para isso criamos uma classe de teste que estende de ActivityInstrumentationTestCase2 ficando assim:
package br.edu.cesar.test;
import android.test.ActivityInstrumentationTestCase2;
import br.edu.cesar.CalculatorActivity;
public class CalculatorActivityTest extends ActivityInstrumentationTestCase2<CalculatorActivity> {
public CalculatorActivityTest() {
super(“br.edu.cesar”, CalculatorActivity.class);
}
}
Depois de criarmos a classe de teste, precisamos implementar o construtor desta classe que deve fica como no código acima. A classe de teste deve dizer para o framework de teste do android qual aplicação deve ser testada, passando por parâmetro do super construtor o pacote e o .class da activity a ser testada. Logo após a criação do construtor podemos passar pra alguns métodos “genéricos” que podem ajudar nos testes em si. São eles: setUp() – Este método herda do método setUp() do JUnit, portanto tem a mesma característica de ser usado para preparar o ambiente antes de cada teste ser executado. tearDown – Este método também herda do JUnit e também tem a mesma característica de ser usado para finalizar o ambiente corretamente quando necessário após cada teste executado. Utilizando o método setUp(), primeiramente pegamos a instancia da activity que vai ser testada e inicializamos alguns views da mesma para interegir a aplicação calculadora. Outra coisa importante que precisamos fazer no teste para que o mesmo possa utilizar aplicação para interagir é desabilitar o modo touch da activity, fazendo isso temos o seguinte código para o método setUp():
É importante lembrar que no inicio da classe estou declarando todos os objetos que estamos utilizando nos códigos dos métodos, como por exemplo mActivity que é um objeto do tipo activity e a mesma esta declarada no inicio da classe como voces podem ver no código do projeto de teste que esta disponivel neste link.
Para entender melhor de onde estou pegando os editText e os botões, deem uma olhada no código do projeto Calculadora, no qual disponibilizei no post anterior. Após criar a classe e implementar o metódo setUp() podemos partir para a implementação do teste em si. Para criar um teste que interaja com a aplicação e analise o resultado esperado, basta criar um método que comece com a palavra “test” no inicio do nome do teste que o framework de teste do android reconhece o mesmo como teste para ser executado. No nosso exemplos demos o nome de testCalculadoraSoma001. Neste teste vamos pegar as instâncias das views carregadas no método setUp() e vamos interagir com a mesma, mas para tal, precisamos criar uma thread especifica de UI para que essa interação ocorra. Pegamos a instancia da activity que temos e chamamos o método runOnUiThread() e dentro do run da nova runnable, a gente interage com as views, como por exemplo pegamos os editText da aplicação e populamos com os valores desejados e depois colocamos o foco no botão somar. O código do teste fica assim:
public void testCalculatorSoma001() {
mActivity.runOnUiThread(new Runnable() {
@Override
public void run() {
e1.setText(“2”);
e2.setText(“8”);
bSomar.requestFocus();
}
Após interagirmos com as view apenas enviamos o evento de pressionamento do center key do teclado com com método sendKey, e como o resultado da operação vem numa nova activity, temos que pegar a instancia da nova activity que vai ser exibida com o método waitForMonitor() passando por parâmetro uma classe que fica monitorando o sistema aguardando que a nova activity que definimos para que o mesmo monitore la no método setUp. Após conseguirmos pegar a instancia da nova activity que vai mostrar o resultado, pegamos o valor que está no TextView result e verificamos se o valor é o mesmo do esperado com o método assertEquals que tem a mesma características dos asserts do JUnit. Por fim apenas precisamos executar o projeto, e para isto basta clicarmos com o botao direito em cima da classe de teste, no nosso caso CalculadoraActivityTest e selecionar a opção Run as-> Android JUnit Test. A execução do teste você pode conferir no video abaixo.
No vídeo acima podemos ver que temos dois testes, o primeiro esta relacionado ao código que coloquei acima testCalculatorSoma001() no qual passamos o valores 2 e 8 para os editTexts e esperamos que o resultado seja igual a 10. O segundo teste vamos deixar por sua conta para praticarem. O valores passados para os editText são 2 e 81 respectivamente e o resultado esperado é uma mensagem de erro que esta dentro do arquivo string.xml (dentro de res/values) do projeto da calculadora que passamos o código no post anterior. A mensagem de erro é a string “Número Inválido”.
Por enquanto é isso pessoal, após utilizar este framework que o android prover eu tirei algumas conclusões, principalmente em algumas situações como por exemplo que dei na qual a aplicação a ser testada possui mais de uma activity e as mesma utilizam intents entre si e quando queremos testar aplicações dos quais não temos acesso ao código mas apenas ao .apk . Nesses casos implementar teste utilizando apenas o framework de teste do google se torna muito trabalhoso e complicado. No próximo post eu vou mostrar um exemplo da diferença de um teste implementado da forma que é recomendado pelo google e implementado utilizando uma biblioteca chamada robotium.
Olá pessoal. Estou de volta para dar continuidade a meu último post sobre automação de testes para aplicações Android e neste post vou detalhar como implementei a nossa calculadora fajuta do Bdb para que possamos entender os conceitos básicos de Android e depois conseguirmos automatizar o testes para esta plataforma.
Primeiramente, como falei no post anterior temos que alinhar o ambiente de desenvolvimento que estamos usando. No meu caso eu uso o Eclipse Classic 3.6.2 instalei o plugin ADT. Para mais detalhes de como configurar seu ambiente, veja aqui.
Como todo começo de projeto, vamos no menu principal do eclipse: File->New->Other… e la na janela wizard temos a opção Android Project que nos leva a seguinte tela que devemos colocar o nome do projeto (Calculadora). Depois de colocar o nome do projeto e clicarmos em Next, vamos para a tela que devemos selecionar o Build Target. Como todos devem saber o Android já evoluiu bastante desde do seu surgimento no mercado com a versão 1.5 mais conhecida como Cupcake até o mais recente e famosa versão 4.o ou Ice Cream Sandwich que promete integrar todo o ecosistema entre smartphones e tablets, mas isso não vem ao caso aqui. No caso da nossa calculadora, ela foi implementada para a versão 2.3.1 (API Level 9) e é o que eu recomendo para que todos usem no momento para que possamos ter um alinhamento das atividades aqui no post.
Depois que escolhermos o Build Target, vamos para a seguinte tela na qual definimos o nome do pacote no qual nossa activity principal ficará disponível e também já vamos ter uma sugestão do nome da activity principal que é o nome do projeto + a palavra Activity no final. Nesta última tela você verá também a opção de criar um projeto de teste para este projeto que você esta criando no momento, mas vamos deixar esta opção desmarcada e no próximo post vou mostrar como criamos um projeto de teste para esta aplicação.
Assim que o nome do projeto, o Build Target, nome do pacote e o nome da activity principal são definidos, o projeto Calculadora vai ser criado com a seguinte estrutura:
Nosso primeiro passo vai ser no arquivo main.xml dentro de res/layout que é o arquivo responsável pela interface visual da activity que vamos implementar. No Android a estrutura da aplicação é dividida em algumas camadas e a camada de interface com o usuário é mais comumente definida no xml. O primeiro passo é selecionar o layout que vamos trabalhar na nossa aplicação, no nosso projeto a layout definido não vai fazer muita diferença, portando fica de livre escolha de vocês qual usar, no nosso código, definimos o relative layout. Para mais detalhe de cada layout suportando no Android, leiam aqui. No nosso projeto de calculadora vamos trabalhar com duas activities e dois xml de layout o primeiro xml (main.xml) temos um TextView (Nome da aplicação), dois editText (Campos para usuario digitar os operandos) e 4 buttons (um botão para cada operador básico). O segundo xml (result.xml) de layout temos apenas um textView que é para exibir o resultado da operação selecionada pelo usuário na tela anterior.Obviamente poderíamos exibir o resultado na mesma tela mas fizemos dessa forma com um próposito que veremos no próximo post quando formos falar das 2 maneiras de automatizar os testes dessa calculadora.
Para ver como ficou os arquivos xml e também os arquivos .java que vou explicar nos parágrafos seguintes, baixe o código da nossa aplicação neste link .
Depois de definido o layout vamos para a implementação em si. Primeiramente, vamos ao básico e criamos uma classe chamada Operators.java com todos os métodos de cada operação básica da nossa calculadora, esta classe será instanciada pela activity principal e seus métodos serão chamados de acordo com os eventos que a nossa activity principal tratar.
Na primeira activity, que é a nossa activity principal (CalculadoraActivity.java) definimos qual layout vamos usar (main.xml) e definimos também alguns atributos que vamos utilizar para pegar as instancias dos Views (componentes visuais, Ex: Buttons) que definimos no main.xml e no qual vamos tratar os eventos que serão gerados pelos usuários ao interagir com estes views, como por exemplo o clique no botão (OnClick). A nossa segunda activity (ResultActivity.java) é a tela que simplesmente pega o resultado “empacotado” pela primeira activity e exibe no textview que esta definida pelo layout result.xml.
Um último detalhe e não menos importante é o arquivo strings.xml que fica dentro da pasta res/values. Nesse arquivo definimos algumas “variáveis” no qual podemos ter acesso de várias parte do cógido, como nos arquivos de layout, no código das activities, etc…
No nosso caso definimos o o valores para todos os views utilizados pela aplicação, como por exemplo o nome na aplicação que é definido no arquivo mais.xml para o TextView esta setado no arquivo strings.xml como app_name e seu respectivo valor é Calculadora.
Após todo esse trabalho a nossa calculadora fajuta do Bdb vai ficar com essa cara como na imagem aqui abaixo:
Bem, por enquanto já temos o suficiente para nos divertimos um pouco durante a semana e no nosso próximo post eu vou finalmente revelar como podemos fazer alguns testes automáticos para esta nossa calculadora fajuta. Aproveitem o restante da semana para por em prática os conceitos básicos passados aqui e brinquem de alterar o código para entender um pouco mais como a coisa toda funciona. Uma ótima semana para todos e até o próximo post.
Olá pessoal, este ano vou começar com uma pequena série de posts e um pouco DIFERENTE dos posts habituais para falar mais uma vez de teste na prática. Obviamente para ser diferente eu vou deixar este primeiro post um desafio para todos assim como eu tive um desafio no final do ano passado para preparar e ministrar uma disciplina de teste de software para uma turma de desenvolvedores que estava participando de um curso de desenvolvimento para Android. Preocupado em deixar as aulas de teste mais interessantes, eu arrisquei adaptar meu material para algo que fosse bastante prático e relevante para essa turma e por isso dei uma estudada no Android e como desenvolver aplicações e criar testes automáticos para o mesmo e acabei descobrindo algumas coisas que o SDK disponibiliza que gostaria de compartilhar com vocês.
Antes de começarmos a desenvolver testes para o Android, preciso passar algumas informações relevantes para que todos possam conseguir ter um entendimento completo de como automatizar alguns testes para aplicações em Android e também consigam completar o desafio que deixarei neste post.
Para podermos automatizar testes para aplicações Android, precisamos entender alguns de seus componentes básicos, que são: Activities, Services, Content Providers e Broadcast Receivers.
Activities – Uma activity é um dos componentes do Android mais usados nas aplicações pois ele é que fornece uma tela com a qual os usuários podem interagir. Por exemplo dicar um número de telefone, escrever uma sms, ou visualizar um mapa. Para cada activity é dada uma “janela” na qual “desenhamos” uma interface de usuário. As “janelas” normalmente preenche toda a tela, mas também podem ser menores do que a tela e flutuar em cima de outras “janelas”.
Services – São componentes de aplicação que podem executar operações de longa duração em segundo plano, portanto não fornecem uma interface de usuário. Um serviço pode ser iniciado por uma aplicação e ele continuará a ser executado em segundo plano, mesmo se o usuário trocar para outra aplicação.
Content Providers – Como o nome já explica, Content Providers é componente responsável por armazenar e recuperar os dados e torna-los acessível para todas as aplicações, ou seja são os provedores de conteúdo. A única forma de compartilhar dados entre aplicações no Android é através de content providers, pois não existe área de armazenamento comum que todos os pacotes Android podem acessar.
Broadcast Receivers – É um componente que responde a anúncios de todo o sistema de broadcast. Muitos brodcast provenientes do sistema, como um broadcast anunciando que a bateria está fraca ou uma sms foi recebida. As aplicações também podem iniciar os broadcast, por exemplo, para permitir que outras aplicações saibam que alguns dados foram disponibilizados para eles usarem. Os broadcast receivers também não possuem interface de usuário, mas eles podem criar uma notificação de barra de status para alertar o usuário quando um evento de broadcast ocorreu.
Bem , depois desta uma breve introdução, vamos por a mão na massa e desenvolver uma calculadora bem simples para que depois possamos automatizar alguns testes para essa aplicação. Quem quiser se aprofundar um pouco mais sobre como desenvolver aplicações para Android pode dar uma olhada neste site para desenvolvedor da Google.
Essa calculadora que desenvolvi possui algumas restrições para cada uma das operações básicas (somar, subtrair, multiplicar e dividir) com o objetivo de exemplificar o uso de algumas técnicas de criação de teste para os alunos da turma e essas técnicas de criação de testes não vem ao caso neste post nem nos seguintes que virão, o nosso objetivo aqui é explicar como desenvolver e automatizar testes para aplicações Android. Outro fator relevante que devo deixar claro é que eu utilizei o eclipse com o plugin ADT para desenvolver meu projeto em Android. Para saber como configurar seu ambiente, veja aqui.
Após configurar o ambiente vamos ao nosso desafio:
Vou deixar alguns requisitos básicos da nossa calculadora para que você possam tentar desenvolver e no próximos post disponibilizarei o nosso código e explicarei passo a passo como o desenvolvi. Logo abaixo segue os requisitos da aplicação que vamos automatizar os testes mais na frente:
Nome: Aplicativo Calculadora Fajuta
[REQ001] Tela principal deve possuir dois campos (EditTexts) para inserir valores e um botão (Button) de cada funcionalidade da calculadora, que são:
– SOMAR
– SUBTRAIR
– MULTIPLICAR
– DIVIDIR
[REQ002] A operação SOMAR só efetua soma de números entre 0 e 10, pois a calculadora é fajuta. O resultado deve ser mostrado em um texto (TextView) no canto inferior da tela.
[REQ003] A operação SUBTRAIR é um pouco mais evoluída e consegue efetuar a subtração de números entre 0 e 50. O resultado deve ser mostrado em um texto no canto inferior da tela e caso seja um resultado negativo, o mesmo deve estar na cor vermelha.
[REQ004] A operação MULTIPLICAR deve multiplicar apenas números pares.
[REQ005] A operação DIVIDIR, da mesma forma da operação Somar, só efetua a divisão de números entre 0 e 10.
E claro que qualquer dúvida por mais simples que seja, podem comentar aqui neste post e terei o prazer de responder o mais rápido possível. Para os mais tímidos, podem me mandar um email que tem no meu perfil aqui do Bdb. Boa sorte a todos !!! 🙂
Nesta sexta vou falar mais um pouco sobre a evolução cientifica mas desta vez com foco na biotecnologia.
Drº Michio mais uma vez diz que estamos fazendo uma transição de meros observadores passivos da dança da natureza para sermos coreográfos ativos da natureza.
A revolução biotecnológica nos permitirá entender como o nosso corpo funciona e como podemos modifica-lo para o nosso favor. Com o projeto Genoma Humano (1990-1995), nós obtivemos o mapeamento de todos os códigos genéticos do ser humano. Num futuro não tão longe, podemos imaginar que cada pessoa vai possuir um manual de instrução pessoal, um manual que diz todo o seu código genético e quais doenças você pode ter e como podemos curá-las.Basicamente é como se nosso corpo fosse um enorme programa extremamente complexo e nós pudéssemos reprograma-lo para corrigir defeitos contido nele.
A terapia genética é um exemplo de como podemos manipular os genes das pessoas e mudar o rumo de uma vida, este video mostra um exemplo real que aconteceu com uma criança chamada Alexander Locke que nasceu com uma doença grave no qual seu corpo não possui um sistema imunológico (conhecido SCID), e quando submetido a uma terapia genética teve uma reversão do quadro clínico em pouquissimo tempo e hoje ele leva uma vida normal com seus pais. VocÊ pode estar se perguntando porque não temos a cura para doenças como câncer, aids, cardíacas, etc. O fato é que a SCID é um defeito genético simples que envolve apenas uma “linha” de gene, enquanto essas outras doenças são causadas por várias linhas de gene interagindo com o ambiente. Mas isso não quer dizer que torna impossível encontrar a cura dessas doenças através de uma terapia genética, mas isso com certeza levará um tempo para que se possa mapear todas as possibilidades de sequencia genética que causam essas doenças para que as mesmas possam ser “reprogramadas”.
Reservem uma hora para assistir esse video do Dr. Michio e surpreenda-se o que o futuro nos pode reservar.
A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo mais divertido, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.
O TGIF de hoje é especial, principalmente para os americanos e canadenses, que é a sexta seguinte ao dia de Thanksgiving (data criada pelo presidente Abraham Lincoln em 1863, definida como a quarta quinta-feira do mês de novembro). Nesta quinta feira a maioria dos americanos definitivamente dedicam o dia para agradecer a Deus pelos bons acontecimentos ocorridos durante o ano.
No dia seguinte, muitos dos americanos e canadenses continuam agradecendo a Deus, mas desta vez por ser o Black Friday, pois isso a data de hoje o TGIF transforma em TGIBF (Thank God is BLACK Friday). Por esta razão muitos correm para as lojas e fazem fila para para comprar produtos com descontos realmente agressivos, principalmente os produtos eletrônicos que ganham os maiores descontos.
No Brasil parece que as lojas estão querendo trazer esta ideia para cá, timidamente, mas estão. Muitas lojas se juntam em um único site e lançam promoções para na tentativa de antecipar as compras de final de ano. Será que esta moda pega ? O que vocês acham ? Os descontos que as lojas brasileiras estão dando realmente são vantajosos ?
Uma coisa é certa, não dá pra comparar os preços dos produtos lá nos EUA com os do Brasil e dia-a-dia, e no Black Friday muito menos. Caso você esteja pensando em viajar para lá no ano que vem no intuito de passear e comprar, vale a pena se programar para ir na ultima semana de novembro. Veja aqui como se preparar para este dia no qual o comércio vira um verdadeiro carnaval 🙂
A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo mais divertido, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.
Bytes don't Bite! 