Como utilizar o Barcode Scanner Emulator (guia passo a passo)

Porque é que os programadores recorrem a um emulador

A maior parte das equipas não tem um leitor de reserva junto de cada computador portátil. Mesmo quando o hardware existe, está muitas vezes ligado a um posto de QA, a um terminal de POS partilhado ou a uma linha de pré-produção que outra pessoa já está a usar. Por isso, uma depuração simples torna-se surpreendentemente lenta.

Um emulador de código de barras resolve essa limitação: permite reproduzir, a partir da própria máquina, uma entrada de teclado semelhante à de um leitor. No ensaio quotidiano do leitor, este pormenor pesa mais do que se espera. Dá para repetir a mesma leitura, alterar o ritmo, activar ou desactivar o sufixo Enter e comparar o comportamento sem sair da secretária.

Situações habituais:

• desenvolvimento local quando o leitor não está ligado à máquina
• testes de regressão quando a QA precisa de valores de código de barras repetíveis
• testes de caixa e de POS em que o foco e o sufixo são decisivos
• ambientes de demonstração em que os fluxos do leitor têm de ser mostrados depressa

Passo 1: perceber o comportamento a simular

Antes de configurar o que quer que seja, defina o que conta como comportamento «correcto» do leitor no fluxo em ensaio. A maioria dos leitores USB actua como uma cunha de teclado. Introduz os caracteres rapidamente no campo com foco e, com frequência, acrescenta Enter no fim.

Este pormenor é importante. Colar texto num campo não testa realmente a reacção do ecrã durante a leitura. Apenas demonstra que o campo consegue guardar o valor. Uma boa configuração do Barcode Scanner Emulator é útil precisamente porque simula o comportamento do leitor, em vez de o substituir por escrita manual.

Passo 2: escolher um único fluxo concreto

Evite objectivos vagos como «testar a leitura». Um objectivo melhor é específico, por exemplo:

1. ler um código de produto no campo de pesquisa do artigo
2. submeter automaticamente com Enter
3. acrescentar o produto ao cesto
4. devolver o foco ao campo de pesquisa

Este grau de detalhe importa porque as falhas ligadas a códigos de barras vivem muitas vezes nos passos à volta da leitura. O valor pode ser válido e, ainda assim, a interface falhar porque o foco mudou, o Enter disparou cedo de mais ou um gestor de validação correu duas vezes.

Em ferramentas de operações de comércio electrónico, o alvo pode ser um formulário de consulta de encomenda. Nos testes de POS, é frequentemente o ecrã de venda. Em software de armazém, pode ser um formulário de recepção ou um fluxo de contagem de stock.

Passo 3: usar valores de código de barras realistas

O valor de ensaio deve parecer-se com os dados que o sistema recebe em produção. Se a aplicação espera EAN-13, use valores de 13 dígitos. Se o servidor associa cadeias de código de barras a SKU internos, use códigos que existam mesmo nos dados de teste.

Convém manter uma biblioteca curta de valores conhecidos:

• um código de produto válido
• um código desconhecido
• um código mal formado ou demasiado curto
• um valor com zeros à esquerda
• um valor-limite que acciona uma regra concreta

Parece elementar, mas separa um ensaio superficial de um ensaio útil. O teste do leitor melhora muito quando se deixa de tratar cada leitura como o mesmo acontecimento.

Passo 4: acertar o ritmo e o comportamento do sufixo

É no ritmo que se escondem muitas falhas reais. Há interfaces que funcionam na perfeição quando o valor aparece de uma só vez e falham quando os caracteres chegam em sequência rápida. Outras aguentam até o leitor acrescentar Enter e o ecrã submeter no momento errado.

Ao configurar o emulador, experimente mais do que uma variação:

• sem sufixo, para confirmar que o campo captura o valor em bruto
• sufixo Enter, para ensaiar a pesquisa e a submissão
• escrita rápida, para imitar uma entrada agressiva de leitor
• escrita um pouco mais lenta, para revelar gestores de eventos sensíveis ao tempo

Se o fluxo depender de pesquisa com atraso, de validação na alteração ou da gestão do foco depois da leitura, este passo é obrigatório. É, regra geral, o que separa «funciona na minha máquina» de «funciona em produção».

Passo 5: ensaiar o foco como faria um operador real

Na prática, as falhas de foco são mais frequentes do que as falhas de interpretação do código. Uma leitura pode estar tecnicamente correcta e, mesmo assim, estragar o fluxo porque o cursor está no campo errado. Por isso convém ensaiar o caminho feliz e alguns erros realistas.

Num ecrã de POS, por exemplo, espera-se que o campo de pesquisa do produto recupere o foco depois de o artigo ser acrescentado. Se isso não acontecer, a leitura simulada seguinte pode cair num campo de quantidade, num campo de desconto ou num sítio inútil. O emulador serve muito bem para reproduzir isto, porque o mesmo cenário pode ser disparado vezes sem conta, sem as variações da escrita manual.

Erros habituais que fazem perder tempo

• usar um único código de barras e presumir que todos os formatos se comportam da mesma forma
• saltar o Enter apesar de os leitores de produção o acrescentarem
• colar o texto à mão em vez de usar uma entrada semelhante à do leitor
• ignorar a recuperação do foco depois de erros de validação ou de diálogos modais
• ensaiar apenas o campo do código, e não o fluxo completo

A atitude mais útil é esta: teste o comportamento à volta da leitura, não apenas o valor.

O que conta mesmo na prática

Na maior parte dos casos, o problema não está no próprio código de barras.

Está no que a interface faz logo a seguir à leitura.

Quem conseguir reproduzir esse instante de forma consistente, sobretudo com o ritmo e o comportamento do Enter, corrige as falhas muito mais depressa do que quem depende só do hardware.