Ansible: Testando Playbooks

Ansible é uma excelente ferramenta para automatização de tarefas.

Cria-se uma lista de computadores e instalando neles um servidor SSH e Python 3, é possível automatizar a instalação de programas, alteração de configurações e, o meu favorito, atualização dos computadores.

No maior estilo do TDD (Test Driven Development), muitas vezes, queremos ter certeza que algo está funcionando antes de prosseguir com a execução do playbook.

Exemplos destes casos são:

  • A nova configuração funciona?
  • O usuário realmente pode (não pode) usar usar sudo?
  • Login do usuário root está mesmo desativado?
  • O firewall liberou/bloqueou a porta HTTP?

Podemos criar testes como esses com certa facilidade e inclusive podemos escolher entre a máquina remota ou local para executar os comandos, o que é essencial para alguns testes.

Abaixo mostro dois exemplos, testando as permissões de um usuário do servidor remoto e testando se o computador local pode fazer login como root.

# Arquivo: tasks/testes.yml
---
- name: TESTE Verificar se o usuário 'admin' pode usar SUDO sem senha
  # Teste no servidor remoto:
  # - su admin -c "xxx": executa o comando xxx como admin;
  # - whoami: imprime o nome do usuário; e
  # - Esperamos que imprima 'admin' (sem o sudo) e em seguida
  #   imprima 'root' (com sudo).
  ansible.builtin.command: |
    su admin -c "whoami; sudo whoami"
  register: result
  changed_when: false
  failed_when: >
    result.stdout_lines[0] != 'admin'
    or result.stdout_lines[1] != 'root'
  timeout: 5

- name: TESTE Negar login do usuário 'root' port SSH
  # Teste no computador local:
  # - SSH, ativando senha e desativando chave pública;
  # - whoami: um comando qualquer para ser executado; e
  # - Esperamos que a tentativa de login seja negada.
  ansible.builtin.command: >
    ssh -oPasswordAuthentication=yes -oPubkeyAuthentication=no
    -p{{ ansible_port }} root@{{ ansible_host }} whoami
  register: result
  changed_when: false
  failed_when: "'Permission denied (publickey)' not in result.stderr"
  timeout: 5
  # Esta parte final definie que o teste é executado no computador local
  # (que executa o Ansible).
  # Desativamos ansible_become para que use o usuário atual, em vez de
  # usar sudo para se tornar root.
  delegate_to: localhost
  vars:
    ansible_become: false

Rodando Testes de Unidade com Wine no Linux

Muitas vezes desejamos compilar e executar testes de unidade para a plataforma Windows. No entanto, reiniciar sua máquina e dar boot no Windows só para testar fica meio na contramão.

Uma alternativa é instalar o MinGW e o Wine, para podermos compilar e para executar os testes de unidade plataforma Windows, sem sair do conforto do Linux.

Para instalar o MinGW e o Wine:

# MinGW - Windows 32-bit:
sudo apt install gcc-mingw-w64-i686 g++-mingw-w64-i686

# MinGW - Windows 64-bit:
sudo apt install gcc-mingw-w64-x86-64 g++-mingw-w64-x86-64

# Wine
sudo apt install wine

Para compilar para a plataforma Windows usamos os compiladores MinGW para C ou C++, para 32-bit ou 64-bit.

CompiladorWindows 32-bitWindows 64-bit
C (GCC)i686-w64-mingw32-gccx86_64-w64-mingw32-gcc
C++ (G++)i686-w64-mingw32-g++x86_64-w64-mingw32-g++
Compiladores MinGW para C/C++ em 32-bit ou 64-bit.

Por exemplo, para compilar os arquivos test_unit.c e unit.c e para Windows 32-bit usamos:

i686-w64-mingw32-gcc test_unit.c unit.c -o test.exe

Então, para rodar o executável no próprio Linux, através o Wine, usamos:

wine test.exe

Conclusão

Podemos executar testes de unidade da plataforma Windows (32-bit ou 64-bit), sem sair do Linux, usando o Wine.

Para rodar um executável qualquer com o Wine, no entanto, pode ser necessário fornecer DLLs (bibliotecas). Porém, a princípio, um teste de unidade não deve depender de nada externo, pois todas as dependências devem ser fakes (falsos) ou mocks (imitadores) e, portanto, não deveria cair neste problema.

Se o seu teste PRECISA de alguma DLL, ele provavelmente ele se encaixa melhor no grupo de testes de integração, não de testes de unidade.

TDD: Testando código C/C++ com Gcov

No post anterior (TDD: Testando código C/C++ com Boost.Test), explicamos como se cria uma suíte de testes com a biblioteca Boost.Test. Muito útil para testar a funcionalidade correta do código.

Neste post mostramos como utilizar o Gcov para verificar se todo o código é executado pelos testes. Criamos uma biblioteca simples e um conjunto de testes para ela.

Ferramentas de code coverage (cobertura de código) como Gcov são muito utilizados para “Desenvolvimento a partir de testes” (TDD – Test Driven Development).

No TDD desenvolvemos os códigos e seus testes em paralelo, para verificar que o código funciona e, no futuro, poder verificar se alguma mudança no código tenha causado um bug.

A análise da cobertura de código auxilia no TDD, identificando partes do código que não estão sendo testadas por completo.

Continue lendo “TDD: Testando código C/C++ com Gcov”

TDD: Testando código C/C++ com Boost.Test

Neste post mostramos como utilizar a biblioteca Boost.Test para testar seus códigos. Podemos compilar a biblioteca junto aos testes, sendo também possível utilizar uma versão pré-compilada para melhorar o tempo de compilação.

Bibliotecas de teste são muito utilizados para “Desenvolvimento a partir de testes” (TDD – Test Driven Development).

No TDD desenvolvemos os códigos e seus testes em paralelo, para verificar que o código funciona e, mais importante, no futuro poder facilmente verificar se alguma mudança no código tenha causado um bug.

Continue lendo “TDD: Testando código C/C++ com Boost.Test”