Cunha de teclado e emulador de código de barras: diferenças essenciais

O que significa cunha de teclado

Um leitor em cunha de teclado comporta-se como um teclado. Ao ler um código, envia os caracteres para o campo activo como se alguém os tivesse escrito muito depressa. Essa é uma das razões da popularidade destes leitores: muitas aplicações aceitam a entrada do leitor sem uma integração própria do dispositivo.

Do ponto de vista da aplicação, parece simples. Na prática, traz consigo um comportamento importante:

• entrada rápida e sequencial de caracteres
• dependência do foco actual
• teclas de sufixo opcionais, como Enter ou Tab
• diferenças de ritmo face à escrita manual

Por estes pormenores, o ensaio do leitor revela muitas vezes falhas que um teste corrente de formulários não mostra.

O que faz um emulador de código de barras

Um emulador reproduz, a partir do software, uma entrada semelhante à do leitor. Em vez de se pegar num leitor físico, configura-se o valor e dispara-se o comportamento da leitura no ambiente de trabalho. As boas ferramentas permitem alterar o ritmo e as regras de sufixo, de modo que o resultado fica muito mais próximo da cunha de teclado do que da escrita manual ou de copiar e colar.

Por isso, o emulador é uma ferramenta de desenvolvimento e de QA. Não substitui a definição de cunha de teclado. Ajuda a simular o comportamento do leitor quando o hardware não está disponível, é inconveniente ou é simplesmente mais lento do que a tarefa em curso.

A diferença mais importante

A forma mais limpa de pensar nisto é a seguinte:

• a cunha de teclado é um modo de entrada do leitor
• o emulador de código de barras é uma ferramenta de software que imita esse modo

Quando estas duas ideias se separam, grande parte da confusão desaparece. Deixa-se de perguntar se o emulador «é» uma cunha e passa-se a perguntar se reproduz o comportamento de cunha de que a aplicação depende.

Porque é que esta diferença pesa nos projectos de software

Não se trata apenas de uma discussão de termos. As equipas tomam más decisões de ensaio quando misturam os conceitos. Ou presumem que um leitor físico é obrigatório para cada pequena alteração de fluxo, ou presumem que um emulador substitui toda a validação de hardware.

Nenhuma das duas vias é boa. A primeira atrasa o desenvolvimento. A segunda dá uma confiança falsa. Perceber a distinção ajuda a escolher a ferramenta certa para a camada certa de ensaio.

Quando o emulador é a melhor escolha

Ao construir um formulário, ao depurar o tratamento do foco, ao verificar o sufixo Enter ou ao fazer um teste rápido de POS no posto de trabalho, o emulador costuma ser a melhor escolha. Configura-se mais depressa, repete-se com mais facilidade e é mais prático para o desenvolvimento corrente.

É também por isso que ferramentas como o Barcode Scanner Emulator são úteis. Permitem simular o comportamento do leitor durante o desenvolvimento normal, em vez de transformar cada reprodução de falha num problema de agenda de hardware.

Quando o leitor real em cunha de teclado continua a ganhar

Use o leitor real quando for preciso validar o próprio percurso do aparelho:

• sensação do gatilho e experiência de quem opera
• configuração e emparelhamento do leitor
• problemas de cabo ou de concentrador USB
• restrições do terminal
• particularidades do ambiente da loja ou do armazém

Um emulador não diz se um modelo concreto se desliga depois da suspensão, nem se um terminal de POS bloqueado impede a mudança de modo do aparelho. Isso não é um defeito do emulador. Significa apenas que as duas ferramentas respondem a perguntas diferentes.

Uma comparação breve em linguagem simples

Se a pergunta for «Este ecrã comporta-se correctamente quando um código é lido?», comece pelo emulador.

Se a pergunta for «Este leitor concreto e este ambiente comportam-se correctamente em condições de produção?», use o leitor real em cunha.

Esta divisão simples chega, regra geral, para tornar o ensaio do leitor e o teste de POS muito mais previsíveis.

O compromisso que a maior parte das equipas devia assumir

Para a maior parte das equipas, a divisão certa é directa:

1. usar um emulador no desenvolvimento diário e nas repetições de QA
2. usar leitores físicos na validação de lançamento e nas verificações próprias do ambiente
3. manter os mesmos conjuntos de códigos nos dois ambientes

Isto dá velocidade sem fingir que o hardware deixou de contar. Também torna as sessões de hardware mais valiosas, porque se concentram em problemas que só o hardware revela.

Um exemplo prático

Suponha que o campo de pesquisa de produto do POS funciona quando se escreve à mão, mas falha quando os valores lidos chegam depressa com Enter. É um caso clássico para o emulador, porque o ritmo e o sufixo podem ser ensaiados repetidamente.

Imagine agora o mesmo fluxo a funcionar no computador portátil de desenvolvimento e a falhar no terminal real de caixa porque a configuração do leitor é outra. Aí, o leitor físico em cunha de teclado torna-se a verificação final necessária. As duas ferramentas contam, apenas em pontos diferentes do fluxo.

Em suma

A cunha de teclado e o emulador de código de barras não são ideias concorrentes. Uma descreve o comportamento de muitos leitores. A outra oferece uma forma prática de reproduzir esse comportamento para ensaio. Quando os papéis se separam, a estratégia de ensaio do leitor fica muito mais fácil de explicar e de manter.