O que é o mais maduro BDD Framework for .NET? [fechadas]

StackOverflow https://stackoverflow.com/questions/307895

  •  08-07-2019
  •  | 
  •  

Pergunta

Temos vindo a utilizar BDD - Behavior Driven Development (da perspectiva de Dan Norte) como um mecanismo para testes de aceitação do usuário de discos e desenvolvimento de carro em um par de projetos, com sucesso decente. Até à data embora não tenhamos realmente automatizado os próprios testes.

Agora estou olhando para automatizar os testes, mas não tenho certeza de qual quadro comportamento para trás. Até agora NBehave parece ser o precursor - mas existem outros que eu deveria estar olhando? Existe um 'vencedor' claro no momento?

Foi útil?

Solução

A resposta rápida

Um muito importante ponto para abrir é que existem dois sabores de Behavior Driven Development. Os dois sabores são xBehave e xSpec .

xBehave BDD: SpecFlow

SpecFlow (muito semelhante ao pepino da pilha rubi) é excelente no sentido de facilitar os testes xBehave BDD como critérios de aceitação. No entanto, não fornecem uma boa maneira de escrever testes comportamentais em um nível de unidade. Existem algumas outras estruturas de teste xBehave, mas SpecFlow tem obtido um monte de tração.

xSpec BDD: MSpec

Objetivamente falando. Dadas as estruturas especificações de contexto disponíveis, MSpec tem sido há mais tempo e é a estrutura de contexto / especificação mais amplamente utilizado na comunidade .Net.

O outro quadro xSpec BDD: nspec

Eu, pessoalmente, recomendo nspec (inspirado diretamente por RSpec para ruby). A divulgação completa, eu sou um dos autores do nspec. Você pode fazer BDD simplesmente usando NUnit ou MSTest ... mas eles meio que ficam aquém (é realmente duro para construir contextos de forma incremental). MSpec também é uma opção e é a estrutura de contexto / especificação mais madura para. Internet. e , existem apenas algumas coisas que são mais simples em nspec.

A resposta longa

Os dois sabores de BDD existem principalmente por causa dos benefícios ortogonais que fornecem.

Prós e Contras da xBehave (GWT Sintaxe)

Pros

  • ajuda a facilitar um conversas com o negócio através de um dialeto comum chamado (por exemplo. Dada ...., e dado .... Quando ...... e, quando ....., então .. .. e depois)
  • o dialeto comum pode ser mapeado para o código executável que prova para o negócio que você realmente terminou o que você disse que iria terminar
  • o dialeto é constrição, de modo que o negócio tem de requisitos ambigüidade e torná-lo apto para as frases.

Contras

  • Embora a abordagem xBehave é bom para a condução Critérios de Aceitação de alto nível, os ciclos necessários para mapear Inglês para código executável via atributos torna inviável para expulsar um domínio no nível da unidade.
  • Mapeando o dialeto comum para testes é doloroso (ramp up em seu regex). Cada frase o negócio cria deve ser mapeado para um método executável via atributos.
  • O dialeto comum deve ser rigorosamente controlada para que a gestão do mapeamento não sair da mão. Toda vez que você mudar uma frase, você tem que encontrar o método que diretamente se relaciona com essa frase e corrigir o correspondente regex.

Prós e Contras de xSpec (Contexto / Especificação)

Pros

  • Permite que o desenvolvedor para construir contexto de forma incremental. Um contexto pode ser configurado para um teste e algumas afirmações pode ser realizada contra esse contexto. em seguida, você pode especificar mais contexto (tomando como base o contexto que já existe) e especifique mais testes.
  • No constrição idioma. Os desenvolvedores podem ser mais expressivo sobre como uma determinada parte de um sistema se comporta.
  • No mapeamento necessário entre Inglês e um dialeto comum (porque não há um).

Contras

  • Não é tão acessível pela empresa. Vamos enfrentá-lo, o negócio não gostam de disambiguate o que eles querem. Se nós lhes deu uma abordagem baseada em contexto para BDD, em seguida, a sentença seria apenas ler "Apenas fazê-lo funcionar".
  • Tudo está no código. A documentação contexto está entrelaçada dentro do código (é por isso que nós não precisa se preocupar com o mapeamento de Inglês para o código)
  • Não é tão legível dado um palavreado menos restritiva.

As amostras

O Bowling Kata é um exemplo muito bom .

SpecFlow Amostra

Aqui está o que a especificação ficaria em SpecFlow (novamente, isso é grande como um teste de aceitação, porque ele se comunica diretamente com o negócio):

Arquivo recurso

O arquivo de recurso é o dialeto comum para o teste. 

Feature: Score Calculation 
  In order to know my performance
  As a player
  I want the system to calculate my total score

Scenario: Gutter game
  Given a new bowling game
  When all of my balls are landing in the gutter
  Then my total score should be 0

Scenario: Single Pin
  Given a new bowling game
  When I've hit exactly 1 pin
  Then my total score should be 1
Passo Definition File

O arquivo de definição passo é a execução real do teste, este arquivo inclui os mapeamentos para SpecFlow 


[Binding]
public class BowlingSteps
{
    private Game _game;

    [Given(@"a new bowling game")]
    public void GivenANewBowlingGame()
    {
        _game = new Game();
    }

    [When(@"all of my balls are landing in the gutter")]
    public void WhenAllOfMyBallsAreLandingInTheGutter()
    {
        _game.Frames = "00000000000000000000";
    }

    [When(@"I've hit exactly 1 pin")]
    public void When1PinIsHit()
    {
        _game.Frames = "10000000000000000000";
    }

    [Then(@"my total score should be (\d+)")]
    public void ThenMyTotalScoreShouldBe(int score)
    {
        Assert.AreEqual(score, _game.Score);
    }
}

MSpec Sample, xSpec, Contexto / Especificação 


public class describe_BowlingKata
{
    public static Game game;

    public class when_all_balls_land_in_the_gutter : describe_BowlingKata
    {
        Establish ctx = () => game = new Game();

        Because of = () => game.Frames = "00000000000000000000";

        It should_have_a_score_of_0 = () => game.Score.ShouldBe(0);
    }

    public class when_a_single_pin_is_hit : describe_BowlingKata
    {
        Establish ctx = () => game = new Game();

        Because of = () => game.Frames = "10000000000000000000";

        It should_have_a_score_of_1 = () => game.Score.ShouldBe(1);
    }
}

nspec Sample, xSpec, Contexto / Especificação

Aqui é um nspec exemplo do mesmo kata de bowling: 


class describe_BowlingGame : nspec
{
    Game game;

    void before_each()
    {
        game = new Game();
    }

    void when_all_my_balls_land_in_the_gutter()
    {
        before = () => game.Frames = "00000000000000000000";

        it["should have a score of 0"] = () => game.Score.should_be(0);
    }

    void when_a_single_pin_is_it()
    { 
        before = () => game.Frames = "10000000000000000000";

        it["should have a score of 1"] = () => game.Score.should_be(1);
    }
}

Como você fazer mais e mais BDD, você verá que são necessários ambos os sabores xBehave e xSpec de BDD. xBehave é mais adequado para testes de aceitação, xSpec é mais adequado para testes de unidade e design orientado domínio.

MSpec vs nspec

métricas objetivas, como idade e estabilidade deve ser um fator, e gostaria de convidar a todos para levar isso em consideração. Mas por favor, levar em consideração que os quadros mais recentes podem fornecer uma API mais sucinto, melhor uso de construções de linguagem e construir sobre as lições aprendidas para frameworks últimos . MSpec fornece construções de dado, porque, Ele e Cleanup..but eles têm um custo: inicialização estática para todos os membros, explosão classe, e é sintaticamente rígida por causa de seu uso exclusivo de delegados. Você verá que os testes MSpec mais simples são mais simples em nspec. Aqui está um conjunto de testes mais complexos escrito tanto em MSpec e nspec.

Uma comparação de xUnit, MSpec e nspec: https://gist.github.com/amirrajan/6701522

Ligações Relevantes

RSpec vs pepino (histórias RSpec)

BDD com pepino e rspec - quando é este redundante?

Outras dicas

Confira SpecFlow .

É uma ferramenta inspirado por Pepino, que visa proporcionar uma abordagem pragmática e sem atrito para Acceptance Test Driven Development e Behavior Driven Development para projetos .NET hoje.

integração VisualStudio parece especialmente promissora.

StoryQ parece uma boa alternativa para NBehave com sua interface Fluent. Eu definitivamente verificá-la.

Eu não acho que há um 'vencedor' realmente. Outros enquadramentos incluem SpecUnit.NET projeto e MSpec também está mostrando a promessa com o início de uma Gálio adaptador. Tecnicamente desde IronRuby está no horizonte, rSpec pode ser uma opção para aqueles preparados para ir bleeding edge. NBehave + nspec pode ser o quadro mais velho com a melhor automação, embora eu me vi lutando contra o excessivamente detalhado sintaxe.

Gostaria de verificar todas elas e escolher o quadro que o estilo se adapte às suas projetos melhor. Eles são todos OSS, por isso é difícil de perder, o benefício real é simplesmente em se mudar para BDD.

Eu, pessoalmente, recomendo BDDfy que é grande na minha opinião! É open source, suportes convenção e fluente descrição do cenário base, abrange grandes provas tanto de aceitação e de unidade. Você pode encontrá-lo no GitHub .

Robot Framework também pode ser usado com IronPython fazer ATDD ou BDD em .Net. Eu acho que as capacidades do robô Framework expressão são melhores do que, por exemplo. SpecFlow 's ou nspec ' s. Não forçá-lo a usar uma determinada sintaxe, mas em vez disso usa uma abordagem orientada palavra-chave. Se você estiver testando aplicações web, tem Selenium2Library que fornece ligações para Selenium WebDriver.

Há também Specter , que define uma DSL em Boo para tornar tudo mais natural.

Eu geralmente vão em favor de NBehave, combinado com MbUnit e qualquer DI / zombando de estruturas que você precisa. É um comentário justo por Jim Burger que NBehave é muito detalhado, e eu me encontrar com cut-and-paste às vezes. Ainda assim, ele funciona muito bem - eu estou usando plug-in ReSharper de Gallio, então eu só pegar uma janela de exibição extra. Já não tentei com ccnet ainda, embora.

Confira este blog e seus comentários para inspirar idéias: http : //haacked.com/archive/2008/08/23/introducing-subspec.aspx/

Concordion.NET suporta não somente os BDD, mas também ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd -bdd-atdd / Especificações são escritos na planície Inglês utilizando HTML. IMHO este é um dos benefícios de Concordion.NET. Os documentos HTML podem ser organizados em uma estrutura navegável para construir uma sistema de documentação de estar . E, já que os testes executados contra o sistema, você pode ter certeza a documentação é sempre up-to-date.

Eu estou começando no meu primeiro passeio no BDD com uma pequena aplicação com a minha equipe. As ferramentas que estão a optar por fazer o trabalho são: Specflow com selênio Webdriver para xBehave histórias e MSpec com Machine.Fakes.Moq para um recipiente automocking para os nossos testes de unidade xSpec. Com ReSharper ser ao mesmo tempo o nosso corredor história e as especificações corredor devido à integração apoiada por Specflow e MSpec. Tendo integração nativa em visual studio com R # é uma característica fundamental para nós.

Uma vez que nosso projeto é tudo MVC3 também estará aplicando a orquestrador padrão de separação para os nossos controladores MVC . Isto irá permitir-nos para escrever especificações diretamente contra o orquestrador. Então para nós a escrever histórias diretamente contra o nosso uso do aplicativo.

Desde que eu estou agora a lidar com BDD para testes do sistema para aplicações críticas de segurança, só posso compartilhar minha experiência que você não deve subestimar o poder de "testes escritos em uma linguagem natural" em vez de "código".

Nós sempre focada para oferecer uma linguagem característica, que qualquer um pode entender, sem qualquer conhecimento técnico ou experiência em programação (veja o exemplo specflow acima) e fizemos bem fazê-lo. Além do fato de que eu nunca explicou a sintaxe para ninguém, todo mundo compreendeu imediatamente o significado do teste, desenvolvedor, gerente, e até mesmo testador.

Gostaria de alguma forma evitar um teste escrito em uma linguagem de programação como os exemplos MSpec acima. Se eu aparecer com um teste como este no escritório de um gerente, ele vai me chutar para fora. Mas ele está interessado em testes de leitura à base de pepino-Syntax. As mais caras são capazes de ler e modificar os testes, melhor.

Por último, mas não menos importante, esses testes são portáteis para qualquer outra linguagem de programação, qualquer outro plattform, qualquer outra ferramenta de automação de teste, sem quaisquer alterações.

Mais uma vez, a resposta é mais uma vez:

Não se preocupam com a ferramenta e seus próprio recursos, escolha uma ferramenta que lhe permite alternar facilmente para outra ferramenta a qualquer momento sem perder informações. Ferramentas de ir e vir, meus testes deve durar mais tempo. : -)

Posso recomendar usando SpecFlow. Você tem acesso total à biblioteca .Net completa e todos os seus recursos, seus testes de ficar portátil. Isso pode lhe dar uma vantagem sobre soluções totalmente portáteis como o quadro do robô, se você não se importa portabilidade. No entanto, você sempre pode melhorar a estabilidade e portabilidade de um sistema usando diferentes ferramentas para desenvolvimento e testes. Então testando um software .Net com uma abordagem BDD python com base pode ser uma boa (ou até melhor) ideia em alguns casos.

No entanto, SpecFlow mostrou-se ser estável e à prova de bala, em todos os testes dia, incluindo testes de build noturnos, etc, em projectos de média dimensão. Além disso, integra-se bem no ambiente de teste do Microsoft Unit.

Também confira UBADDAS, específico para UAT encontrada em

https://github.com/KernowCode/UBADDAS

com uma explicação aqui

http://kernowcode.wordpress.com/ (em junho de 2014)

Você pode escrever um teste como este 

[Test]
public void IWantToRegisterANewUser()
{
  var user = new User();
  ICustomer customer = new Customer();

  SoThat(MyBusinessValue.IncreaseCustomerBase)
    .As(user)
    .Given(customer.Register)
    .When(customer.Confirm_Registration)
    .Then(customer.Login);
}

e produz este 

I want to register a new user
  so that Increase customer base
       as user
    given Register customer
     when Confirm customer registration
     then Login customer
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top