BdB Recomenda – Data Generator

BdB Recomenda – É a mais nova seção do blog, que tem como objetivo apresentar sugestões de aplicativos, ferramentas, livros, jogos, cursos, palestras, eventos, etc. que possam contribuir com as suas tarefas diárias ou apenas com boas dicas para seu tempo livre.

Frequentemente encontramos nos projetos que participamos cenários em que precisamos simular grandes volumes de informações na base de dados.

Diversas são as alternativas para solucionar o problema: podemos realizar manualmente a operação desejada diversas vezes ou criar um arquivo de comandos SQL no editor de texto e executar o mesmo na base de dados ou ainda partirmos para a utilização de ferramentas que possam nos auxiliar na tarefa.

O Data Generator, trata-se de uma ferramenta web, que recomendo, devido a sua simplicidade e capacidade de resolver o nosso problema rapidamente, além de se tratar de um projeto open source. Através da mesma podemos gerar dados em diversos formatos: XLS, HTML, XML, CSV e principalmente SQL.

Data Generator Screenshot

De uma maneira extremamente simples podemos utilizar dados: variáveis ou fixos; pré-carregados na ferramenta ou customizados. A figura abaixo, exibe como para cada coluna de um tabela podemos facilmente definir diferentes tipos de dados de acordo com a natureza do campo.

Customizando Dados no Data Generator

O melhor de tudo é que você pode testar a ferramenta sem precisar instalar nada, pois na página do projeto existe uma versão disponível para testes.

Caso você se interesse em continuar usando a aplicação, recomendamos a instalação na sua própria máquina, pois a versão demo possui a limitação de gerar no máximo 200 registros. Mas, não se preocupe, a instalação é extremamente simples, possui apenas 5 passos. E caso ainda tenha dificuldades, encontrei no youtube um vídeo do processo de instalação feito pelo Elias Nogueira do blog SemBugs.

Para mais detalhes na utilização da ferramenta, existe ainda um artigo, que publiquei na revista Testing Experience, com informações mais detalhadas sobre a utilização do Data Generator.

E vocês recomendam outras ferramentas para popular base de dados?

Campus Party 2012 e o empreendedorismo

A Campus Party é considerado o maior evento de tecnologia da América Latina. Em sua quinta edição, o evento foi realizado na cidade de São Paulo e contou com a participação de aproximadamente 7.000 pessoas. Um dos atrativos do evento é a Internet de 20GBit/s, o qual a grande maioria dos “campuseiros” (pessoas que acampam no evento durante a semana toda) se interessam visto a facilidade para fazer Downloads e, principamente, jogar jogos. Aliás, pelo que vi nos 6 dias, a grande maioria esta – literalmente – interessada em jogar jogos on-line {infelizmente}.

Por outro lado, a Campus Party quer – definitivamente – ser reconhecida como um celeiro de criação de novas startups. Em dua quinta edição pode-se notar algumas idéias que deram {estão dando} certo.
Este ano, diversas palestras foram realizadas sobre o tema e foi realizado um reality show pelo Sebrae onde os 3 duplas de empreendedores trabalham em tarefas durante a semana, com consultoria diária e, ao final, o vencedor é apoiado a levar adiante a startup.

Todavia, após 5 anos, aproximadamente 40 mil pessoas já passaram por lá… e conta-se nos dedos idéias e startups que foram criadas na Campus Party. Será que a feira levou muito tempo para acordar com essa nova realidade? Será que os jovens que participam da feira, no decorrer dos 6 dias, não podem ter um foco mais interessante do que “jogar jogo on-line e baixar filmes/séries/etc”? Ou será que o foco das iniciativas/palestras/talks/etc não podem ser melhor direcionado para isso ao invés de ser apenas “eu falo e vocês escutam”? Já passou por lá? Comente sua experiência.

#TGIF – O que você fez durante a semana para ser lembrado?

O #TGIF dessa semana apresenta o áudio de um comentário feito pelo Max Gehringer na CBN, o qual aborda uma questão que vale a nossa reflexão – a regra dos 5%. Segundo a mesma apenas 5% de tudo que escutamos, vemos, falamos, lemos e escrevemos interessa.

Escutem e avaliem de que maneira vocês estão aproveitando suas 2h criativas na semana de trabalho.

“Todo mundo sempre se considera parte dos 5%”

E você acredita na regra dos 5% ? Participe, deixando seu comentário.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo mais diversificado, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– Desafio dos 30 dias

– Achievement Unlocked

Design Centrado no Usuário X Design Centrado no Cliente

Olá mais uma vez. Hoje resolvi falar um pouco sobre um dos maiores dilemas para todos aqueles que querem mudar o mundo mas precisam de alguém para financiar essa mudança. Sim, somos nós, heróis de TI, que com muito esforço utilizamos muitas vezes de recursos que não existem, tempo que nunca é suficiente  e trabalhos que não são sempre reconhecidos.

Um dos maiores dilemas entretanto, é quando nos deparamos com a seguinte situação: Após uma série de estudos, definições e várias sessões de brainstorm, a equipe decidiu adotar a solução A. Entretanto, por algum motivo (que normalmente nem chega ao time) o cliente – que é quem está pagando – decidiu que para todos os envolvidos (usuários finais incluídos) é melhor que seja adotada a solução B. Soou familiar? Como procedemos nesses casos? Por que isso acontece?

Vou tentar responder de trás para frente.

Antigamente, o desenvolvimento de software tinha o foco muito diferente do que temos hoje em dia. Na época em que se alguém quisesse usar um software de planilha eletrônica tinha que recorrer ao Lotus 1-2-3 e, consequentemente, não havia a concorrência que temos hoje, o usuário era por muitas vezes refém de uma situação em que ou ele aprendia a utilizar aquela ferramenta (normalmente lendo um manual extenso e altamente técnico) ou “fazia na mão”. Isso acontecia principalmente porque quem projetava os sistemas eram pessoas que estavam naquele meio comumente (desenvolvedores de software). O que isso quer dizer? Quer dizer exatamente que se o usuário final não tivesse as mesmas habilidades de um programador, não conseguiria usar de forma satisfatória. Isso acontecia porque esse tipo de abordagem – em que o cliente está em foco e o sistema é desenvolvido baseado nos requisitos e desejos do mesmo – se baseia em premissas como:

  • Ênfase no funcionamento do sistema
  • Especialistas (desenvolvedores, designers, testers) trabalhando de forma isolada
  • Não há validação do usuário até o primeiro release
  • Visão de qualidade no produto (ex. número de bugs)
Design Centrado no Cliente
Design Centrado no Cliente

Diferentemente, temos hoje uma abordagem em que o sistema é projetado baseado nos interesses dos usuários que irão utilizar o produto que está sendo desenvolvido. Analogamente, temos então que o design centrado no usuário tem como premissas:

  • Ênfase na interação com o usuário
  • Equipes multidisciplinares trabalhando conjuntamente
  • Validação por parte dos usuários antes mesmo de escrever a primeira linha de código
  • Visão de qualidade baseada na satisfação do usuário
Design Centrado no Usuário
Design Centrado no Usuário

Vemos então que esse tipo de abordagem – a do design centrado no usuário – tem como foco trazer o usuário para dentro do processo. Mas e quando os usuários querem uma coisa diferente do que o cliente quer? Bom, nesse caso o mais prudente é tentar convencer o cliente da importância e do impacto que é ter um projeto que está alinhado com o desejo dos usuários finais. Um produto que não atende as expectativas não vai ser vendido (ou baixado) e não vai gerar lucros e/ou visibilidade. Contudo, nem sempre o cliente vai querer ceder e é aí que entra toda a experiência do profissional para saber lidar com a situação. Não se preocupe se não conseguir, nem todos querem mudar o mundo. Alguns simplesmente não podem fazê-lo.

Se tudo isso soou familiar, não se preocupe. Isso é sinal de que você está no mundo real.

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.