#TGIF – Google Fiber e suas consequências

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: skypefacebookmsn 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.

Anúncios

TMM, o que é isso ?

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 (TPITMMi

Então após essa breve explicação sobre TMM, você consegue ter uma ideia em qual nível TMM da sua empresa ?

Testes de sistemas na nuvem

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
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
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
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 .

#TGIF – Armazenamento na nuvem – qual o melhor custo benefício ?

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.

Clique para ampliar

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.

– Oversose de Informação

– Comprar, jogar fora, comprar

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Como Automatizar Testes de aplicações Android – Parte 4 (Final)

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());
}

protected void tearDown() throws Exception {
try {
solo.finalize();
} catch (Throwable e) {
e.printStackTrace();
}
getActivity().finish();
super.tearDown();
}

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 :

public void testSomar001(){
solo.enterText(0, “2”);
solo.enterText(1, “8”);
solo.clickOnButton(“Somar”);
assertTrue(solo.searchText(“10”));
solo.goBack();
}

public void testSomar002(){
solo.enterText(0, “2”);
solo.enterText(1, “81”);
solo.clickOnButton(“Somar”);
assertTrue(solo.searchText(“Número Inválido”));
solo.goBack();
}

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.

Como Automatizar Testes de aplicações Android – Parte 3

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():

@Override protected void setUp() throws Exception {
super.setUp();
setActivityInitialTouchMode(false);
mActivity = getActivity();
mMonitor = mIntrumentation.addMonitor(ResultActivity.class.getName(), null, false);
e1 = (EditText) mActivity.findViewById(br.edu.cesar.R.id.editText1);
e2 = (EditText) mActivity.findViewById(br.edu.cesar.R.id.editText2);
bSomar = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnSomar);
bSubtrair = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnSubtrair);
bMultiplicar = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnMultiplicar);
bDividir = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnDividir);

}

É 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();
}

});
this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);
oActivity = mIntrumentation.waitForMonitor(mMonitor);
assertNotNull(oActivity);
result = (TextView) oActivity.findViewById(br.edu.cesar.R.id.textview_result2);
assertEquals(“10”, result.getText());
this.sendKeys(KeyEvent.KEYCODE_BACK);
}

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.

Como Automatizar Testes de aplicações Android – Parte 2

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.