Por Fit / FitNesse?

Question

O que é o ponto de usar Fit / FitNesse em vez de testes de integração xUnit de estilo? Ele tem uma sintaxe muito estranho e muito claro na minha opinião.

É realmente apenas para fazer os proprietários do produto escrever testes? Eles não! É muito complicado para eles. Então, por que alguém deveria Fit / FitNesse?

Atualizar Portanto, é totalmente adequado para testes de negócios em regras única?

Answer 1

A questão toda é para o trabalho com não-programadores, as pessoas muitas vezes até mesmo completamente não-técnicos como usuários perspectiva de uma aplicação de negócio, na qual aplicativo deve fazer e, em seguida, colocá-lo em testes. Ao fazer testes trabalho é certamente muito complicado para eles, eles devem ser capazes de discutir tabelas de dados de exemplo preenchidos no exemplo Palavra. E a grande coisa é, ao contrário especificação tradicional, esses documentos viver com a sua aplicação, porque os testes automatizados forçá-lo a atualizá-los.

Introdução Para Fit e Fit fluxo de trabalho por James Shore e siga os links para o resto da documentação se quiser.

---

Update: depende do que você quer dizer com regras de negócio? ;-) Algumas pessoas entendem muito restritiva (como nos motores de regras de negócios, etc.), outros --- de forma muito ampla.

A meu ver, Fit é uma ferramenta que permite que você anote negócios (como no domínio) casos de uso com ricos exemplos realistas em um documento, que os usuários finais ou especialistas de domínio (em alguns domínios) pode compreender, verificar e discutir. Ao mesmo tempo, estes exemplos são em forma legível por máquina para que possam ser usados ??para conduzir testes automatizados, você nem escrever o documento inteiramente por si mesmo, nem requre-los a fazê-lo. Em vez disso, é um produto da callaboration e discussão que reflete a crescente compreensão de que a aplicação vai fazer, em ambos os lados. Exemplos ficam mais ricos como você progride e mais casos de canto são resolvidos.

O aplicativo vai fazer, não como, é importante. É uma forma de especificação funcional. Como tal, é bastante amplo e não realmente organizada por módulos, mas sim cenários de uso.

Os testes que saem de exemplos irá testar o comportamento externo de aplicação em aspectos importantes do ponto de vista empresarial. Sim, você pode chamá-lo de regras de negócio. Mas vamos olhar para exemplo de classificação de crédito de Diego Jancic, apenas com uma pequena torção. E se parte do documento ajuste é 1) listando atributos e suas pontuações e, em seguida, 2) que fornecem dados de cliente e verificar resultados, então quais são as regras de negócios reais: mesa de pontuação (atributos e suas pontuações) ou lógica de aplicação de computação a pontuação para cada cliente (com base na tabela de pontuação)? E quais são testados?

testes

FIT / FitNesse parecer mais adequado para testes de aceitação. Outros testes (quando você não se preocupam com a cooperação com os clientes, usuários, especialistas de domínio, etc, você só quer automatizar testes) provavelmente será mais fácil de escrever e manter em formas mais tradicionais. xUnit é bom para testes de unidade e testes de API. Cada framework web deve ter alguma ferramenta para web app / testar o serviço integrado em seu ciclo Modificar-build-test-Deploy, por exemplo. Django tem o seu cliente de teste pouco. Você tem muito a escolher.

E você sempre pode escrever sua própria ferramenta (ou de preferência ajustar algumas existente) para melhor ajuste (trocadilho intencional) alguns testes em seu domínio de interesse particular.

---

Um pensamento mais geral. É muitas vezes (nem sempre !!!) melhor para codificar seus testes, "regras de negócio" e apenas sobre qualquer coisa, de alguma forma de dados bem definidos, que é interpretado por alguns simples, pedaço genérico de código. Então é fácil de usar os dados de alguma outra forma: gerar documentação, migrar para novos framework de testes, a aplicação porta para novo ambiente / linguagem de programação, o uso de verificar a conformidade com algumas regras externas ou outro sistema (só usar a imaginação). É muito mais difícil para puxar essa informação para fora a partir do código, por exemplo. simples testes de unidade codificados ou regras de negócios.

lojas Fit testar casos como dados. No formato muito específico por causa de como ele é destinado a ser utilizado, mas ainda assim. Seus testes específicos de domínio podem usar diferentes formatos como simples CSV, JSON ou YAML.

Answer 2

A idéia é que você (o programador) define um fácil formato de entender, como uma folha de excel. Em seguida, o proprietário do produto entra a informação que é difícil de entender para as pessoas que não está no negócio ... e você só validar que o código funciona como os espera PO executam Fit. A maneira usada em xUnit, pode ser usado para programadores como uma entrada para fácil de entender ou simples informações. Se você estiver indo para necessidade de digitar um monte de exemplos estranhos com vários campos em seu teste xUnit, ele tornou-se difícil de ler.

Imagine um caso em que você tem que decidir se quer dar um empréstimo a um cliente, com base na idade, Casado / Individual, Quantidade de Childrens, salário, atividade, ... Como um programador, você não pode escrever essa informação; e um gerente de risco não pode escrever um teste xUnit.

Answer 3

Ajuda a reduzir a redundância em regressão e teste de bug. Construir repositório gerenciável de casos de teste. É como construir uma vez e uso para sempre.