Fixture

Um fixture ou test fixture (em português, dispositivo de teste) é um ambiente usado para testar consistentemente algum item, dispositivo ou parte de software. Os fixtures (dispositivos ou acessórios de teste) podem ser encontrados ao testar componentes eletrônicos, softwares e dispositivos físicos.

## Eletrônica

[editar | editar código fonte]

No teste de equipamentos eletrônicos, como placas de circuito, componentes eletrônicos e chips, um dispositivo de teste é um dispositivo ou configuração projetado para manter o dispositivo em teste no lugar e permitir que ele seja testado ao ser submetido a sinais de teste eletrônicos controlados.

Conectores laterais, pinos de centralização, agulhas de teste, peças de pré-centralização. Um Dispositivo de Teste Funcional é um dispositivo complexo para fazer a interface do dispositivo sob teste (DUT) com o equipamento de teste automático (ATE)

Os exemplos são um testador de cama de pregos ou SmartFixture.

## Software

[editar | editar código fonte]

Um fixture de teste de software configura um sistema para o processo de teste de software ao inicializá-lo, satisfazendo assim quaisquer pré-condições que o sistema possa ter.[1] Por exemplo, framework web Ruby on Rails usa YAML para inicializar um banco de dados com parâmetros conhecidos antes de executar um teste.[2] Isso permite que os testes sejam repetidos, o que é um dos principais recursos de uma estrutura de teste eficaz.[1]

### Configuração

[editar | editar código fonte]

Os fixtures de teste podem ser configurados de três maneiras diferentes: em linha, delegado e implícito.

1. A configuração em linha cria o dispositivo de teste no mesmo método que o resto do teste. Embora a configuração em linha seja o dispositivo de teste mais simples de criar, ela leva à duplicação quando vários testes exigem os mesmos dados iniciais.
2. A configuração delegada coloca o dispositivo de teste em um método auxiliar autônomo separado que é acessado por vários métodos de teste.
3. A configuração implícita coloca o dispositivo de teste em um método de configuração que é usado para configurar vários métodos de teste. Isso difere da configuração de delegado porque a configuração geral de vários testes está em um único método de configuração, onde o dispositivo de teste é criado, em vez de cada método de teste ter seus próprios procedimentos de configuração e vincular-se a um dispositivo de teste externo.[3]

### Vantagens e desvantagens

[editar | editar código fonte]

A vantagem de um dispositivo de teste é que ele permite que os testes sejam repetidos, uma vez que cada teste sempre começa com a mesma configuração. Os acessórios de teste também facilitam o design do código de teste, permitindo ao desenvolvedor separar métodos em funções diferentes e reutilizar cada função para outros testes. Além disso, os acessórios de teste pré-configuram os testes em um estado inicial conhecido, em vez de trabalhar com o que restou de uma execução de teste anterior. Uma desvantagem é que isso pode levar à duplicação de acessórios de teste se usar a configuração em linha.[1][3]

### Práticas a evitar

[editar | editar código fonte]

É considerada uma prática ruim quando os acessórios de teste implícitos são muito gerais ou quando um método de teste configura um acessório de teste e não o usa durante o teste. Um problema mais sutil é se os métodos de teste ignoram certos campos dentro do dispositivo de teste. Outra prática ruim é uma configuração de teste que contém mais etapas do que o necessário para o teste; este é um problema visto na configuração em linha.[3]

Um caso de teste é considerado "inseguro" quando modifica seu (s) acessório (s). Um caso de teste inseguro pode tornar os testes subsequentes inúteis, deixando o aparelho em um estado inesperado. Isso também faz com que a ordem dos testes seja importante: um dispositivo de fixação modificado deve ser redefinido se mais testes devem ser executados após um teste inseguro.[1]

### Exemplos

[editar | editar código fonte]

Exemplos de acessórios incluem carregar um banco de dados com um conjunto específico de dados conhecido, apagar um disco rígido e instalar uma instalação de sistema operacional limpa conhecida, copiar um conjunto específico de arquivos conhecidos ou a preparação de dados de entrada, bem como configuração e criação de objetos fictícios.

O software usado para executar testes reproduzíveis sistematicamente em uma parte do software em teste é conhecido como cablagem de teste; parte de seu trabalho é configurar equipamentos de teste adequados.

No xUnit genérico, um dispositivo de teste é tudo o que deve estar instalado para executar um teste e esperar um resultado específico.[4]

Freqüentemente, os fixtures são criados tratando dos eventos setUp() e tearDown() da estrutura de teste de unidade. Em setUp(), cria-se o estado esperado para o teste e em tearDown() limpa o que foi configurado.

Quatro fases de um teste:

1. Configuração (set-Up)
2. Exercício, interagindo com o sistema em teste
3. Verificação, determinando se o resultado esperado foi obtido
4. Destruição, para voltar ao estado original (tear down)

## Ver também

[editar | editar código fonte]

* Teste de unidade

## Referências

1. ↑ a b c d Pereira da Silva, Lucas (10 de junho de 2016). «Execution and code reuse between test classes». 2016 IEEE 14th International Conference on Software Engineering Research, Management and Applications (SERA). [S.l.: s.n.] pp. 99–106. ISBN 978-1-5090-0809-4. doi:10.1109/SERA.2016.7516134
2. ↑ «A Guide to Testing Rails Applications»
3. ↑ a b c Greiler, Michaela; Zaidman, Andy; van Deursen, Arie; Storey, Margaret-Anne (2013). Strategies for Avoiding Text Fixture Smells during Software Evolution (PDF). 10th IEEE Working Conference on Mining Software Repositories (MSR). doi:10.1109/MSR.2013.6624053. Consultado em 24 de janeiro de 2014
4. ↑ Meszaros, Gerard (2007). xUnit Test Patterns: Refactoring Test Code (PDF). [S.l.]: Addison-Wesley Professional. ISBN 978-0-13-149505-0. Cópia arquivada (PDF) em 23 de setembro de 2016

## Ligações externas

[editar | editar código fonte]

* Unit Testing with JUnit, por Yoonsik Cheon
* The Low-Down on fixtures, de A Guide to Testing Rails Applications