Fim do Post Denúncia

É com tristeza que anunciamos o fim do Post Denúncia, e consequentemente do Mapa Brasileiro de Qualidade do Ar. As denúncias de fumaça preta feitas no estado de São Paulo através do aplicativo Post Fumaça Preta não serão mais encaminhadas para a CETESB, e não serão mais coletados os dados de qualidade do ar publicados pelos diversos órgãos que possuem rede de monitoramento. O aplicativo não pode ser mais baixado da Apple Store ou do Google Play, e o site em breve será desligado.

Entendemos que não houve interesse da comunidade em participar do projeto, mesmo após a abertura do código fonte no Github. E também que não houve interesse na disseminação das informações de qualidade do ar em aplicativos ou sites a partir do uso da nossa plataforma. Diante deste cenário, e considerando ainda os custos envolvidos, optamos por retirar o serviço de operação. Caso queira ter acesso aos dados, ou de alguma forma retomar o projeto, por favor envie um email para contato@esign.com.br.

Termômetro da cultura

O manifesto ágil defende que indivíduos e interações devem ser priorizados em relação a processos e ferramentas. A cultura organizacional é, portanto, preponderante para a adoção de práticas ágeis. Nesse processo, é imprescindível identificar barreiras culturais para a colaboração e a comunicação, requisitos da agilidade.

Uma dica para reconhecer tais barreiras é prestando atenção ao que é falado entre as pessoas no dia-a-dia de trabalho. É possível perceber frases repetidas regularmente, tão repetidas que acabam por estabelecer o comportamento padrão. Novos funcionários assumem a postura e o discurso sem muito questionamento (veja a história dos 5 macacos).

Identificar estas frases ajuda a tornar a cultura consciente. Só através dessa consciência ela pode ser compreendida e mudada. Por isso estamos realizando a pesquisa “Termômetro da cultura”, para medir a cultura a partir das frases mais ouvidas e faladas, e daí desenvolver melhores estratégias para a adoção da agilidade nas empresas.

Apesar da nossa pesquisa ser aberta a participantes de empresas distintas, ela pode ser adaptada e aplicada internamente em qualquer empresa. Certamente o resultado dará maior clareza de como os indivíduos interagem e servirá de insumo para a transformação organizacional necessária para a empresa se tornar efetivamente ágil.

Participe da pesquisa! 🙂

Crie seu próprio questionário de feedback de usuário

Como adicionar o mapa de qualidade do ar no seu site ou app

O mapa de qualidade do ar existente no aplicativo Post Fumaça Preta também pode ser disponibilizado no seu site ou aplicativo. Melhor, ele é configurável para apresentar, por exemplo, dados de uma cidade apenas, ou das proximidades de um ponto qualquer do Brasil. Basta passar parâmetros específicos, conforme explicado mais abaixo.

Para adicionar o mapa no seu site, será preciso usar iframes. Neste post, os exemplos serão apresentados desta forma. Para adicionar no seu app, basta abrir no componente browser a URL origem do mapa, acompanhada ou não de parâmetros. Quando não acompanha parâmetros, o mapa mostra o país inteiro, o que poderia ser a visualização inicial desejada.

<iframe src="https://www.postdenuncia.com.br/postfumacapreta/qualidadear.html"/>

Para apresentar somente os dados de qualidade do ar do estado do Rio de Janeiro, adicione ?estado=RJ à URL base. O parâmetro estado aceita qualquer sigla de unidade federativa brasileira. Quando não existem dados de qualidade do ar para a o filtro informado, é sempre apresentado todo o país. No caso do estado do Rio, dados obtidos do INEA e da SMAC são mostrados.

<iframe src="https://www.postdenuncia.com.br/postfumacapreta/qualidadear.html?estado=RJ"/>

Uma alternativa à filtrar por estado, seria filtrar por cidade. Sugestão para sites ligados a municípios, como os de prefeituras. Os dados de qualidade do ar da cidade de Curitiba, capital do Paraná, podem ser apresentados adicionando-se ?cidade=Curitiba à URL base. No momento deste post, são cinco as estações de monitoramento lá, conforme o IAP.

<iframe src="https://www.postdenuncia.com.br/postfumacapreta/qualidadear.html?cidade=Curitiba"/>

Um modo interessante de mostrar o mapa é identificando um ponto para apresentar os dados de qualidade do ar nas proximidades. Neste modo, o ponto é destacado, e as cinco estações de monitoramento mais perto do ponto são identificadas pelas letras A a E, sendo A a estação mais próxima e E a mais afastada do ponto. Quando a estação é selecionada, pode-se conhecer ainda a distância da estação para o ponto. Este tipo de visualização é usada pelo aplicativo Post Fumaça Preta, que identifica o ponto conforme a localização do usuário.

Se você quer mostrar no seu site, por exemplo, a qualidade do ar das redondezas do Estádio do Pacaembu, na cidade de São Paulo, pode definir a Praça Charles Miller como ponto. Assim sendo, basta adicionar ?endereco=Pra%C3%A7a%20Charles%20Miller à URL base. Esta é uma boa alternativa se você não sabe as coordenadas exatas do lugar. Experimente informando seu endereço residencial, lembrando apenas antes de transformá-lo em ASCII.

<iframe src="https://www.postdenuncia.com.br/postfumacapreta/qualidadear.html?endereco=Pra%C3%A7a%20Charles%20Miller"/>

Agora, se você conhece a latitude e a longitude de determinada localização, como da Vila Olímpica do Rio de Janeiro, por exemplo, adicione à URL base o seguinte: ?latitude=-22.985790&longitude=-43.416969. Lembre-se que ambos os parâmetros precisam ser passados em conjunto. Como os smartphones possuem função GPS, é uma excelente opção filtrar pela localização do usuário.

<iframe src="https://www.postdenuncia.com.br/postfumacapreta/qualidadear.html?latitude=-22.985790&longitude=-43.416969"/>

Fique à vontade para adicionar o mapa! Ajudando a disseminar os dados de qualidade do ar, você chama a atenção ao problema da poluição. Com mais pessoas conscientes do problema, mais gente envolvida na solução, mas chance de o resolvermos. Se tiver qualquer dificuldade, não hesite em pedir ajuda 🙂

Edição feita em 24/02/2017: Com o fim do Post Denúncia, os links dos iframes não funcionam mais. Por isso, os iframes deste post foram substituídos pelas imagens correspondentes.

Post Denúncia na trilha Smart Cities do TDC 2016 São Paulo

Na semana passada estive no The Developers Conference falando um pouco sobre a experiência do Post Denúncia, do aplicativo Post Fumaça Preta e do Mapa Brasileiro de Qualidade do Ar. Foi muito bom! Agradeço a oportunidade aos coordenadores da trilha Smart Cities: Jeff Prestes, Alexandre Uehara e Lina Lopes, e a todos os participantes. Tiveram muitas perguntas, que geraram um debate bacana, mesmo com o tempo escasso. Quem quiser continuar a discussão, se envolver com os projetos, fiquem à vontade, é só entrar em contato!

O objetivo da apresentação foi principalmente mostrar os fracassos e sucessos durante estes 3 anos de Post Denúncia, os sonhos que permanecem com o esforço de evoluí-lo, e engajar os desenvolvedores por meio da colaboração. O Post Denúncia nasceu com a motivação de se fazer a diferença na sociedade, e o desejo com a palestra foi mostrar que é possível sim que a comunidade de desenvolvedores use o domínio da tecnologia em prol de um mundo melhor.

 

Acima está a apresentação feita lá, e que foi publicada no SlideShare. No slide sobre o Post Denúncia, foi mostrado o vídeo institucional, publicado no YouTube, aqui. No slide sobre o aplicativo Post Fumaça Preta, foi mostrado o mapa online com todas as denúncias feitas através do app no estado de São Paulo e, portanto, encaminhadas para a CETESB. Este mapa também pode ser visto aqui. No slide sobre o Mapa Brasileiro de Qualidade do Ar, ele foi mostrado da mesma forma somente com as informações do estado de São Paulo, como pode ser visualizado aqui. Caso queira fazer o download do arquivo PowerPoint, ele está disponível aqui.

Por fim, tirada do livro Fearless Change: Patterns for Introducing New Ideas, de Mary Lynn Manns e Linda Rising, deixo a mesma mensagem: “Remember how powerful you are. Never forget the power of the individual to make a difference. Enroll people in that possibility and change the world, change your community, change your family, change yourself.” (President Carter)

Antes da mudança

Imagine uma empresa tradicional, de mais de 20 anos, hierárquica, burocrática, com muitas áreas, a média de tempo de casa é maior do que 10 anos. Imagine também que o sistema disponibilizado ao cliente é um grande monolito, um backlog leva cerca de 6 meses pra chegar à produção, o processo todo tem diversos gargalos.

Apesar das dificuldades, novos produtos são colocados no mercado com sucesso, o relacionamento com os clientes é ótimo. A concorrência não é tão forte então a ideia de que está tudo bem permanece. O esforço pra entregar software é alto mas, mal ou bem, no final das contas dá tudo certo, e parece que todos se satisfazem com o resultado.

Por conta dessa sensação de estabilidade, existe uma alta resistência à mudança. Iniciativas de inovação ocorrem, é verdade, mas normalmente não recebem a atenção necessária. Muitos empecilhos aparecem para a adoção, multiplicados à complexidade e ao custo e ao risco e a não sei mais o quê. Afinal, “em time que está ganhando não se mexe”.

Não mais que de repente, ameaças começam a surgir: startups que focam na fatia de mercado negligenciada, tecnologias disruptivas que prometem derrubar a tecnologia dominante, modelos de negócio que põem em risco os modelos já estabelecidos, empresas maiores interessadas em aquisição para aumentar o market share. Todos são surpreendidos.

É preciso reagir, mas parece que a empresa perdeu a habilidade de responder rápido. Todo mundo trabalha a tanto tempo da mesma forma, e com um efeito positivo, que é difícil até reconhecer o que pode estar errado. Talvez o mais fácil seja apontar os culpados em outras áreas, na esperança de proteger os seus. Frente à nova perspectiva, negação.

A realidade vai se desenhando aos poucos, os riscos cada vez mais iminentes, e a empresa ainda sem se adequar. A cultura é muito forte, e não se muda de uma hora pra outra. Mesmo com sinalizações claras de que é preciso fazer algo o quanto antes, prefere-se esperar um pouco mais, pra “ver no que vai dar”. Diante da necessidade de mudar, protelação.

Se você se identificou de algum modo com essa resumida história, por favor coloque suas impressões. É fato que ela poderia se desenrolar por caminhos distintos, mas acredito que todos apontariam para uma inevitável mudança corporativa, de um jeito ou de outro, você deve concordar. Vou parar por aqui, fiquemos com a imaginação do que vem depois 🙂

Open Data

opendata

Com o advento da Internet, e a Era da Informação, surgiu um movimento para a abertura dos dados. Este movimento defende o acesso irrestrito a dados, sua utilização e reprodução. Ganhou força com a disponibilização de dados públicos por vários governos, em prol da transparência. Para criarmos o mapa brasileiro da qualidade do ar, recorremos aos que diversos órgãos ambientais atualizam em seus sites.

Embora tenhamos tido o cuidado de informar sobre a constante extração dos dados para consolidação numa base de dados própria, nem sempre a resposta foi positiva. Nossa justificativa sempre foi o entendimento da natureza pública do dado, e a importância em disseminá-lo, mas nem todos os órgãos se sentiram confortáveis com a visibilidade dada, talvez preocupados com possíveis questionamentos.

Dados abertos não são só importantes para replicação, como fazemos hoje no mapa, que inclusive cita como fonte o órgão origem. Dados abertos são imprescindíveis para, após trabalhados, gerar conhecimento, e agregar valor. Os dados de qualidade do ar combinados com os dados de atendimento de pessoas com problemas respiratórios em hospitais públicos, por exemplo, podem indicar o quanto a poluição prejudica a saúde.

A bem da verdade, existe mesmo uma controvérsia com relação às classificações de qualidade do ar adotadas no país. Os profissionais da saúde as consideram pouco rigorosas, pois não seguem as recomendações da OMS (Organização Mundial da Saúde), levando a população a achar que a qualidade do ar está boa, quando na realidade não está. Além disso, argumentam que o cálculo dos índices não é claro, e contestam fatores econômicos porventura usados.

Ao recorrer a dados abertos, é preciso estar ciente que, independentemente da origem, eles podem não ser exatos. Pode existir um grau de imprecisão, o que não os necessariamente desqualifica. Mesmo se os dados fossem obtidos de sensores portáteis, espalhados pela cidade, fatores como as condições físicas do equipamento, sua aferição e a própria transmissão dos dados implicariam numa maior ou menor confiabilidade.

Outro ponto de atenção no uso de dados abertos é a dependência ao formato origem. Quando não existe um padrão, e a fonte pode adotar o formato que quiser, a qualquer tempo, complica. Isto quer dizer que a extração desenvolvida especificamente para aquela origem pode deixar de funcionar de uma hora pra outra, simplesmente porque a fonte resolveu mudar a vírgula de lugar. Normalmente não se conhece quem consome os dados, e não existe o menor compromisso em comunicar qualquer alteração. Monitore, portanto, cada mecanismo automático de extração de dados abertos.

Um formato ruim para extrair dados é o PDF. No vídeo do TED abaixo Ben Wellington fala sobre isso, sobre como a falta de padronização atrapalha, e sobre como descobriu o pior lugar para se estacionar em Nova Iorque:

Colaboração

Resolvi fazer uma pausa na série de posts sobre ferramentas de testes para falar um pouco sobre colaboração. Esse assunto aparece cada vez mais nas empresas, mas ao mesmo tempo que vem como a solução de muitos problemas, não me parece ser bem compreendido, e por vezes parece assustar, e cria resistências.

Isso porque colaboração exige uma mudança de mentalidade, de comportamento, e a grande maioria das empresas brasileiras é muito hierarquizada, e dividida em silos. E isto faz com que geralmente as pessoas busquem se defender, mais do que se ajudarem. Pior ainda quando a ajuda é interpretada como ameaça.

Quando se colabora, de verdade, os muros deixam de existir. São construídas pontes. Todos entendem que estão no mesmo barco e, no fim, o que importa mesmo é o cliente, e só. Os problemas passam a ser de todos, qualquer um pode se envolver na solução. Ninguém espera demanda, todos trabalham para entregar valor.

Não é à toa que muitas empresas tem buscado criar uma cultura colaborativa. Normalmente, a colaboração é a saída para sobreviver, em mercados cada vez mais competitivos. Quando o negócio corre risco, a colaboração vem para agilizar processos, inovar, e até criar negócios novos, se reinventar, com o foco exclusivo no cliente.

Numa cultura colaborativa, os erros são encarados com normalidade, o aprendizado é estimulado, o conhecimento é compartilhado, a experiência é dividida. As pessoas podem ter suas especialidades, mas acabam evoluindo em outras disciplinas como consequência da integração com outras áreas. O potencial das pessoas é valorizado, e desenvolvido.

Não adianta ter a colaboração como valor da empresa, estampada em apresentações corporativas, se ela não é adotada na prática, não é vivida. Ela requer o compromisso individual, engajamento, e até proteção. A mudança de hábito não se obtém de um dia para o outro, é um processo, com alto e baixos, mas que precisa de disciplina, pra virar realidade.

O benefício claro da colaboração, além dos resultados nos negócios, é a motivação das pessoas, é a satisfação de fazer parte de um time que agrega valor ao cliente, é o propósito. Cada pessoa sabe a importância do seu trabalho, sabe que sua participação é fundamental para o resultado final. A colaboração empodera as pessoas, as torna mais felizes.

Estamos vivendo uma época em que a colaboração cresce exponencialmente na sociedade. Informação disseminada, redes sociais, economia compartilhada, o indivíduo saiu do anonimato para marcar presença no mundo, para mudar o mundo. As empresas precisam se ajustar à esse novo momento, ou ficarão pra trás.

A figura abaixo foi tirada do post do blog do Tanmay Vora que comenta um excelente post do Aaron Sachs e do Anupam Kundu, da ThoughtWorks, falando justamente da mudança de mentalidade necessária para a transformação das empresas, frente aos desafios atuais. Quanto à colaboração, eu destacaria “from hierarchies to networks” e “from controlling to empowering”.

organization-transformation

Qualidade da sua UI com Selenium

selenium

Este é o segundo post da série que tem como objetivo disseminar a cultura da qualidade de software, apresentando ferramentas que permitam os desenvolvedores incorporarem no seu dia-a-dia a prática do teste do código que produzem. Desta vez testaremos a interface do usuário (UI) da aplicação logistics, a mesma aplicação web que usamos como exemplo no post anterior, e cujo código está aqui.

O frontend da aplicação logistics foi construído com o AngularJS, framework JavaScript da Google que implementa o padrão de arquitetura MVC, e que tem uma característica bem peculiar motivo principal da sua fama: o two-way data binding. O AngularJS foi combinado ao Bootstrap, conhecido framework frontend com origem no Twitter, na criação da página única da aplicação (single-page application).

Vamos testar as funcionalidades da página web de forma automatizada com o Selenium. Com esta ferramenta, é possível simular uma pessoa usando literalmente a aplicação, ou seja, digitando dados num campo, clicando num botão, etc. Só que isso de modo previamente programado, bastando escolher dentre os vários web browsers que ela suporta onde será feita a simulação. No nosso caso, o Mozilla Firefox.

Para reproduzir o comportamento do usuário e testar nossa UI, usamos um design pattern do Selenium chamado Page Object Model, onde as telas são representadas por classes Java, e os elementos das telas são seus atributos (a escolha desta solução teve inspiração neste excelente post no blog da Toptal). Apesar da nossa aplicação ser SPA, fizemos uso de telas do tipo modal, abertas a partir da tela principal, e cada foi representada:

  • HomePage.java (tela principal)
  • AddMapModal.java (tela modal para adicionar novo mapa)
  • AddRouteModal.java (tela modal para adicionar rotas a um mapa)
  • BestRouteModal.java (tela modal para descobrir melhor rota)
  • RemoveMapModal.java (tela modal para confirmar a execução de mapa)

Bem, vamos mostrar um pouco de código. Todo o código deste exemplo está aqui. Fique à vontade para clonar o repositório GIT e contribuir com o projeto. Primeiro, seguem as dependências referentes ao Selenium, para serem adicionadas ao pom.xml:

        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-firefox-driver</artifactId>
            <version>2.53.0</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-support</artifactId>
            <version>2.53.0</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>2.53.0</version>
            <scope>test</scope>
        </dependency>

Na página principal da aplicação, veja por exemplo o trecho referente à tela modal para adicionar rotas a um mapa existente:

  <script type="text/ng-template" id="addRouteModal.html">
    <div class="modal-header">
      <h3 class="modal-title">{{map.name}}: New Route</h3>
    </div>
    <div class="modal-body">
      <div class="row">
        <div class="col-md-4">
          <label for="originName">Origin:</label>
          <input type="text" id="originName" ng-model="route.origin.name" class="form-control" autofocus>
        </div>
        <div class="col-md-4">
          <label for="destinationName">Destination:</label>
          <input type="text" id="destinationName" ng-model="route.destination.name" class="form-control">
        </div>
        <div class="col-md-4">
          <label for="distance">Distance (Km):</label>
          <input type="text" id="distance" ng-model="route.distance" class="form-control">
        </div>
      </div>
      <div class="row" style="margin-top: 20px;">
        <div class="col-md-12">
          <alert>The opposite route ({{route.destination.name}} -> {{route.origin.name}}) will be also created.</alert>
        </div>
      </div>
    </div>
    <div class="modal-footer">
      <button name="addRouteOkButton" class="btn btn-primary" ng-click="ok()">OK</button>
      <button name="addRouteCancelButton" class="btn btn-warning" ng-click="cancel()">Cancel</button>
    </div>
  </script>

Esta é a tela:

newroute

E este é o código de AddRouteModal.java, classe Java que representa a tela em questão:

public class AddRouteModal {

    private final WebDriver driver;

    @FindBy(tagName = "h3")
    private WebElement heading;

    @FindBy(id = "originName")
    private WebElement originName;
    
    @FindBy(id = "destinationName")
    private WebElement destinationName;
    
    @FindBy(id = "distance")
    private WebElement distance;

    @FindBy(name = "addRouteOkButton")
    private WebElement addRouteOkButton;

    @FindBy(name = "addRouteCancelButton")
    private WebElement addRouteCancelButton;

    public AddRouteModal(WebDriver driver) {
        this.driver = driver;
        PageFactory.initElements(driver, this);
    }

    public boolean isPageOpened(String map) {
        return heading.getText().contains(map.concat(": New Route"));
    }
    
    public void setOriginName(String origin) {
        originName.clear();
        originName.sendKeys(origin);
    }
    
    public void setDestinationName(String destination) {
        destinationName.clear();
        destinationName.sendKeys(destination);
    }
    
    public void setDistance(String d) {
        distance.clear();
        distance.sendKeys(d);
    }
    
    public void clickOnAddRouteOkButton() {
        addRouteOkButton.click();
    }
    
    public void clickOnAddRouteCancelButton() {
        addRouteCancelButton.click();
    }

}

Observe que, na construção da classe, os atributos do tipo WebElement são inicializados pelo PageFactory. Cada atributo deste tipo representa um elemento de interface, que para ser identificado usa-se o annotation FindBy. Especificamente nesta classe, os elementos foram encontrados a partir do tagName, id e name, mas isto pode ser feito por maneiras distintas, inclusive utilizando XPath.

Feita a inicialização dos atributos, seus métodos podem ser invocados e os elementos de interface é que reagem. Durante a execução do teste, a execução de addRouteCancelButton.click(), por exemplo, faria com que a tela modal fosse fechada. Do mesmo modo, métodos como clear e sendKeys de WebElements que representam campos de formulário, respectivamente refletem a limpeza e a definição de seu conteúdo.

Uma vez construídas as classes que reproduzem o comportamento das telas, foi possível desenvolver o teste propriamente dito. A classe UITest realiza os testes na sequência (annotation FixMethodOrder do JUnit), passando por todas as funcionalidades de telas, como se fosse numa interação entre uma pessoa e a aplicação rodando no browser. O trecho de código abaixo, por exemplo, testa a criação de rota, usando a classe AddRouteModal, apresentada anteriormente:

        home.clickOnAddRouteButton();
        AddRouteModal modal = new AddRouteModal(driver);
        assertTrue(modal.isPageOpened(MAP));
        
        modal.setOriginName(PLACEA);
        modal.setDestinationName(PLACEB);
        modal.setDistance("10");
        modal.clickOnAddRouteOkButton();
        assertTrue(home.isAlertAddRouteSuccessMessage(PLACEA, PLACEB));

Enfim, esperamos ter contribuído um pouco mais para disseminar o conhecimento de ferramentas de teste. O Selenium é um ótima ferramenta para garantir o bom funcionamento da sua interface com o usuário e, melhor, de maneira automatizada. O teste pode ser adicionado ao processo de entrega contínua ou simplesmente acionado de forma ad hoc.

Críticas e sugestões, sintam-se à vontade 🙂

Qualidade da sua API REST com REST-assured

rest-assured

Este é o primeiro post de uma série que visa ajudar os desenvolvedores a testarem efetivamente o código que produzem e, assim, fomentar a cultura da qualidade de software. As ferramentas que serão apresentadas testam uma aplicação exemplo de logística, chamada logistics, cujo código está disponível no nosso Github.

A aplicação permite criar mapas e rotas dentro destes mapas. O objetivo é encontrar o melhor caminho, entre o ponto de origem e o de destino, dada a autonomia do veículo e o preço do combustível. O melhor caminho é o mais barato. Uma API REST foi desenvolvida para expor as funcionalidades da aplicação, e vamos agora mostrar como testá-la com o REST-assured.

    <dependencies>
        <dependency>
            <groupId>com.jayway.restassured</groupId>
            <artifactId>rest-assured</artifactId>
            <version>2.5.0</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

Para testar, é preciso que a aplicação esteja disponível num servidor Java EE (particularmente, usamos o Wildfly). Por padrão, o REST-assured assume que a aplicação está disponível na porta 8080 do localhost, mas isso pode ser alterado definindo-se os campos baseURI e/ou port. No nosso teste, não precisamos alterar, então basta informar à ferramenta o endpoint:

    @Before
    public void setup() {
        RestAssured.basePath = "/logistics/api/maps";
    }

Este código faz parte do projeto logistics-test-restassured, com duas classes JUnit que utilizam o REST-assured: RESTTestRESTResponseSchemaTest. Ambas testam as funcionalidades da aplicação logistics na sequencia determinada pelos nomes dos métodos, comportamento definido pela annotation FixMethodOrder com o parâmetro MethodSorters.NAME_ASCENDING. A ordem dos testes é a seguinte:

  1. Criação de um mapa
  2. Verificação da existência do mapa recém criado
  3. Verificação da constraint de nome único para mapas
  4. Criação de rotas para o mapa
  5. Verificação da constraint de nome único para rotas
  6. Exclusão de uma rota
  7. Obtenção da melhor rota
  8. Exclusão do mapa

O REST-assured se baseia no modelo given-when-then para a realização dos testes. Segundo esse modelo, partindo de um cenário (given) e um comportamento (when) subsequente, teremos o resultado esperado (then). A diferença entre as duas classes é basicamente como avaliam o resultado esperado. Primeiro, vejamos como o teste da criação de um mapa é feito na RESTTest:

    @Test
    public void testA() {
        mapSlug = RestAssured
            .given()
                .contentType(ContentType.JSON)
                .body("{\"name\": \"REST-assured Test\"}")
            .when()
                .post()
            .then()
                .statusCode(200)
                .contentType(ContentType.JSON)
                .body("code", equalTo(200))
                .body("status", equalTo("success"))
                .body("data", notNullValue())
                .body("data.slug", notNullValue())
            .extract()
                .path("data.slug");
    }

Neste método, o primeiro da sequencia, é testada a criação de um mapa com o nome “REST-assured Test”, submetido no formato JSON via POST. É esperada uma resposta 200 do HTTP (sucesso) e o resultado retornado, também no formato JSON, representa o mapa recém criado no campo data, obrigatoriamente com o slug que o identifica definido. O slug é então extraído para uso nos testes posteriores (requer dependência abaixo).

        <dependency>
            <groupId>com.jayway.restassured</groupId>
            <artifactId>json-path</artifactId>
            <version>2.5.0</version>
            <scope>test</scope>
        </dependency>

Vejamos agora como o teste da criação de um mapa é feito na RESTResponseSchemaTest:

    @Test
    public void testA() {
        RestAssured
            .given()
                .contentType(ContentType.JSON)
                .body("{\"name\": \"REST-assured JSON Schema Test\"}")
            .when()
                .post()
            .then()
                .statusCode(200)
                .contentType(ContentType.JSON)
                .body(matchesJsonSchemaInClasspath("map-response-schema.json"));
    }

Observe que parte das mesmas condições, mas o resultado é avaliado de modo distinto. Como o resultado esperado está no formato JSON, é possível constrastá-lo com seu JSON schema, que nada mais é do que a descrição do JSON definido como resposta. Podemos dizer que o JSON schema está para o JSON assim como o XSD está para o XML. O REST-assured valida então se o JSON schema contido em map-response-schema.json bate com o retorno da API (requer dependência abaixo).

        <dependency>
            <groupId>com.jayway.restassured</groupId>
            <artifactId>json-schema-validator</artifactId>
            <version>2.5.0</version>
            <scope>test</scope>
        </dependency>

Bem, estes exemplos tentam mostrar como o REST-assured é uma excelente ferramenta para testes de APIs REST. Uma vez definidos os endpoints, os métodos, as entradas e saídas, é possível utilizá-la para garantir a qualidade da API. Os testes podem ser executados por linha de comando (mvn test) ou podem fazer parte de um pipeline de entrega contínua.

Espero que tenha gostado, e aguarde o próximo post 🙂

Mapa brasileiro de qualidade do ar

 

Desde a versão 2.0 do aplicativo Post Fumaça Preta, disponibilizada para iOS, passamos a informar a qualidade do ar a partir da localização do usuário. Além de ter acesso às informações oriundas da estação de monitoramento mais próxima, o usuário passou a poder visualizar o mapa que apresenta toda a rede de monitoramento. Cada estação posicionada no mapa informando: a data e a hora de publicação dos dados, a classificação e o índice da qualidade do ar, o poluente determinante no cálculo do índice, e ainda a evolução do IQA através de um gráfico histórico.

Para que isso fosse possível, muitas linhas de código e uma técnica particular, chamada web scraping. Com ela, foi possível extrair de forma automatizada e constante as informações de qualidade do ar publicadas nos sites dos diversos órgãos ambientais brasileiros que possuem rede de monitoramento (para realizar essa extração, utilizamos o Jsoup), e centralizá-las numa base de dados estruturada. Criamos então algo ainda inexistente no momento, o mapa brasileiro de qualidade do ar!

Como nem tudo são flores, algumas dificuldades são encontradas para manter o mapa atualizado, como aumentar a abrangência à medida que mais órgãos passam a publicar os dados, se adaptar a novos formatos adotados pelos órgãos nos seus sites, e conhecer a localização das estações de monitoramento. E apesar dos órgãos se basearem nos padrões definidos pelo Ministério do Meio Ambiente, podem possuir tabelas de classificação e nomenclaturas diferentes, que o mapa precisa seguir à risca.

Hoje são 7 os órgãos ambientais cujos dados publicados de qualidade do ar são obtidos: CETESB (Companhia Ambiental do Estado de São Paulo), FEAM (Fundação Estadual do Meio Ambiente – MG), IAP (Instituto Ambiental do Paraná), IEMA (Instituto Estadual de Meio Ambiente e Recursos Hídricos – ES), INEA (Instituto Estadual do Ambiente – RJ), INEMA (Instituto do Meio Ambiente e Recursos Hídricos – BA) e SMAC (Secretaria Municipal de Meio Ambiente – Rio de Janeiro). Nos avise se souberem de mais órgãos!

O módulo de qualidade do ar faz parte atualmente do Post Denúncia, mas dada sua relevância, queremos separá-lo. É nosso desejo usá-lo como base para a construção de uma plataforma aberta voltada especificamente para a qualidade do ar. O Post Fumaça Preta passaria então a ser cliente dessa nova plataforma, que disponibilizaria uma API para uso não somente por aplicativos, mas por sites e pessoas em geral. Esperamos que curtam a ideia e se engajem no projeto!