O que significa “stub” em programação?

Por exemplo, o que significa nesta citação?

A integração com uma API externa é quase uma garantia em qualquer aplicativo da web moderno. Para testar com eficácia essa integração, você precisa removê -la. Um bom stub deve ser fácil de criar e consistentemente atualizado com as respostas atuais e reais da API. Nesta postagem, descreveremos uma estratégia de teste usando stubs para uma API externa.

Um stub é uma substituição controlável para uma Dependência Existente (ou colaborador) no sistema. Usando um stub, você pode testar seu código sem lidar diretamente com a dependência.

Dependência Externa - Dependência Existente:
É um objeto em seu sistema com o qual seu código em teste interage e sobre o qual você não tem controle. (Exemplos comuns são sistemas de arquivos, threads, memória, tempo e assim por diante.)

Forexample no código abaixo:

public void Analyze(string filename)
    {
        if(filename.Length<8)
        {
            try
            {
                errorService.LogError("long file entered named:" + filename);
            }
            catch (Exception e)
            {
                mailService.SendEMail("admin@hotmail.com", "ErrorOnWebService", "someerror");
            }
        }
    }

Você deseja testar o método mailService.SendEMail () , mas para fazer isso você precisa simular uma Exceção em seu método de teste, então você só precisa criar um objeto Fake Stub errorService para simular o resultado desejado, então seu código de teste será capaz de testar o método mailService.SendEMail () . Como você pode ver, é necessário simular um resultado que é de uma outra Dependency que é o objeto da classe ErrorService (objeto Dependency Existente).

Um stub , neste contexto, significa uma implementação simulada.

Ou seja, uma implementação simples e falsa que está em conformidade com a interface e deve ser usada para teste.

Em termos do Layman, são dados fictícios (ou dados falsos, dados de teste ... etc.) Que você pode usar para testar ou desenvolver seu código até que você (ou a outra parte) esteja pronto para apresentar / receber dados reais. É o "Lorem Ipsum" de um programador.

O banco de dados de funcionários não está pronto? Faça um simples com Jane Doe, John Doe ... etc. API não está pronta? Invente um falso criando um arquivo .json estático contendo dados falsos.

Neste contexto, a palavra "stub" é usada no lugar de "mock", mas por uma questão de clareza e precisão, o autor deveria ter usado "mock", pois "mock" é uma espécie de stub, mas para teste. Para evitar mais confusão, precisamos definir o que é um esboço.

No contexto geral, um stub é um pedaço de programa (normalmente uma função ou um objeto) que encapsula a complexidade de invocar outro programa (geralmente localizado em outra máquina, VM ou processo - mas nem sempre, também pode ser um local objeto). Como o programa real a ser invocado geralmente não está localizado no mesmo espaço de memória, invocá-lo requer muitas operações, como endereçamento, execução da invocação remota real, empacotamento / serialização dos dados / argumentos a serem passados ​​(e o mesmo com o resultado potencial), talvez até lidando com autenticação / segurança e assim por diante. Observe que, em alguns contextos, os stubs também são chamados de proxies (como proxies dinâmicos em Java).

Um mock é um tipo muito específico e restritivo de stub, porque um mock é uma substituição de outra função ou objeto para teste. Na prática, costumamos usar simulações como programas locais (funções ou objetos) para substituir um programa remoto no ambiente de teste. Em qualquer caso, o mock pode simular o comportamento real do programa substituído em um contexto restrito.

Os tipos mais famosos de stubs são obviamente para programação distribuída, quando é necessário invocar procedimentos remotos ( RPC ) ou objetos remotos ( RMI , CORBA ). A maioria das bibliotecas / estruturas de programação distribuídas automatiza a geração de stubs para que você não precise escrevê-los manualmente. Os stubs podem ser gerados a partir de uma definição de interface, escrita com IDL por exemplo (mas você também pode usar qualquer linguagem para definir interfaces).

Normalmente, em RPC, RMI, CORBA e assim por diante, distinguem -se os stubs do lado do cliente , que cuidam principalmente do empacotamento / serialização dos argumentos e da execução da invocação remota, e dos stubs do lado do servidor , que cuidam principalmente do desempacotamento / desserialização os argumentos e realmente executa a função / método remoto. Obviamente, os stubs do cliente estão localizados no lado do cliente, enquanto os stubs do servidor (geralmente chamados de esqueletos) estão localizados no lado do servidor.

Escrever bons stubs eficientes e genéricos torna-se bastante desafiador ao lidar com referências de objetos. A maioria das estruturas de objetos distribuídos, como RMI e CORBA, lidam com referências a objetos distribuídos, mas isso é algo que a maioria dos programadores evita em ambientes REST, por exemplo. Normalmente, em ambientes REST, os programadores de JavaScript fazem funções stub simples para encapsular as invocações AJAX (serialização de objeto sendo suportada por JSON.parsee JSON.stringify). O projeto Swagger Codegen fornece um amplo suporte para a geração automática de stubs REST em vários idiomas.

Stub é uma definição de função que possui o nome de função correto, o número correto de parâmetros e produz um resultado fictício do tipo correto.

Ajuda a escrever o teste e serve como uma espécie de andaime para tornar possível executar os exemplos antes mesmo de o design da função estar completo

Você também tem uma estrutura de teste muito boa para criar tal stub. Um dos meus preferidos é o Mockito. Também existe o EasyMock e outros ... Mas o Mockito é ótimo, você deve lê-lo - pacote muito elegante e poderoso

Essa frase é quase certamente uma analogia com uma fase na construção de uma casa - "retocar" o encanamento. Durante a construção, enquanto as paredes ainda estão abertas, o encanamento áspero é colocado. Isso é necessário para a construção continuar. Então, quando tudo ao seu redor está pronto o suficiente, a pessoa volta e adiciona torneiras, vasos sanitários e o produto final. (Veja, por exemplo, como instalar um encanamento Stub-Out .)

Quando você "elimina" uma função em programação, você constrói o suficiente para contornar (para teste ou para escrever outro código). Então, você volta mais tarde e substitui-o pela implementação completa.

RPC Stubs

• Basicamente, um stub do lado do cliente é um procedimento que parece ao cliente como se fosse um procedimento de servidor que pode ser chamado.
• Um stub do lado do servidor olha para o servidor como se fosse um cliente de chamada.
• O programa cliente pensa que está chamando o servidor; na verdade, está chamando o stub do cliente.
• O programa servidor pensa que foi chamado pelo cliente; na verdade, é chamado pelo stub do servidor.
• Os stubs enviam mensagens uns aos outros para fazer o RPC acontecer.

Fonte

"Cortar uma função significa que você escreverá apenas o suficiente para mostrar que a função foi chamada, deixando os detalhes para depois, quando você tiver mais tempo."

De: SAMS Teach yourself C ++, Jesse Liberty e Bradley Jones