Sont BDD tests tests d'acceptation?

Question

Ou, si vous avez BDD tests, avez-vous besoin de quelque chose comme Fitnesse?

Answer 1

BDD "tests" existent à différents niveaux de granularité, tout le chemin jusqu'à la première vision du projet. La plupart des gens savent à propos des scénarios. Un peu de gens se souviennent que les BDD a débuté avec le mot "devrait" comme un remplacement pour JUnit du "test" - comme un remplacement pour le TDD. La raison, j'ai mis "tests" entre guillemets est parce que la BDD n'est pas vraiment à propos de l'essai; il est axé sur la recherche d'endroits où il y a un manque ou l'inadéquation de la compréhension.

En raison de cette attention, les conversations sont beaucoup plus importants que la BDD outils.

Je vais le dire encore une fois. Les conversations sont beaucoup plus importants que la BDD outils.

Les tests d'acceptation n'a pas de mandat de de la les conversations, et travaille généralement à partir de l'hypothèse que les tests que vous écrivez sont le droit des tests. Dans la BDD, nous supposons que nous ne savons pas ce que nous faisons (et ne savent probablement pas que nous ne savons pas). C'est pourquoi nous utilisons des choses comme "Donnée, Quand, Alors" - de sorte que nous pouvons avoir des conversations autour de scénarios et / ou au niveau de l'unité d'exemples. (Ce sont les deux niveaux de la plupart des gens sont familiers avec l'équivalent de tests d'acceptation et les tests unitaires - mais il va jusqu'à l'échelle).

Nous ne les appelons pas des "tests d'acceptation" parce que vous ne pouvez pas demander à une personne d'affaires "s'il vous Plaît m'aider avec mon test d'acceptation". Ils vont vous regarder avec un vraiment bizarre, squinty regard et puis vous licencier en tant que geek girl. 93% d'entre vous ne voulez pas que.

Essayez "je voudrais vous parler du scénario où..." à la place. Ou, "Pouvez-vous me donner un exemple?" L'une de ces sont bonnes. En les appelant "les tests d'Acceptation" commence à faire les gens pensent que vous êtes en train de faire des tests, ce qui impliquerait que vous savez ce que vous faites et vous voulez juste pour faire sûr que vous avez fait il. À ce stade, les conversations ont tendance à se concentrer sur la façon dont rapidement vous pouvez obtenir la mauvaise chose, au lieu de sur le fait que vous sortez quelque chose de mal.

Et vous obtenez la mauvaise chose. Vraiment, honnêtement, vous êtes. Même si vous pensez que vous ne l'êtes pas, c'est seulement parce que vous ne comprenez pas de deuxième ordre de l'ignorance. Vous ne savez pas que vous ne savez pas, et c'est OK, tant que vous avez trouvé les endroits où l'on pourrait savoir que vous ne connaissez pas. (Vous ne trouverez pas tous d'entre eux. Ne laissez pas la catégorisation paradoxe de vous tenir jusqu'à la nuit.)

La seule façon de vraiment obtenir ce droit est d'obtenir toutes les exigences à l'avant, et vous savez ce qui arrive quand vous essayez de faire cela. C'est le droit. C'est de la Cascade. Rappelez-vous les heures supplémentaires? Le week-end de travail? Les sept années où pas une chose que vous avez créé, il fait de la production? Si vous voulez éviter cela, vous n'avez qu'une seule chance: supposons que vous avez tort, avoir des conversations à ce sujet pour être moins mal, alors acceptez le fait que vous êtes toujours mal et y aller de toute façon. L'écriture de tests trop tôt signifie que vous avez encore plus de chance de se tromper, et il est maintenant plus difficile à changer et tout le monde pense que vous avez raison et le PM est de mesurer votre vitesse et maintenant vous avez à cœur d'être faux pour un autre 2 semaines. Et - pire - que vous êtes sur le point de test que vous avez tort, trop.

Une fois de plus. Les conversations sont beaucoup plus importants que la BDD outils.

S'il vous plaît, s'il vous plaît, ne pas se concentrer sur les outils. Les outils ne sont qu'un mécanisme de saisie des conversations et de s'assurer qu'ils sont lus dans le code. Les scénarios ne sont pas un remplacement pour les conversations, pas plus que de 3 x 5 index est une carte de remplacement pour les exigences.

Cela dit, si vous devez commencer avec un outil, mis Slim derrière Fitnesse sorte qu'il peut fonctionner belle Donné / Quand / Arrêtera sans avoir à jouer avec l'Ajustement des tableaux et des accessoires. GivWenZen est basé sur Slim et l'un ou l'autre des roches. FitSharp est l'équivalent pour ceux d'entre vous dans le .NET espace. Ou tout simplement utiliser le Concombre, ou SpecFlow, ou frapper un peu personnalisé DSL* que va faire le travail d'amende pour des années.

La transparence: *j'ai écrit qu'un seul. Et des morceaux de JBehave. Je souhaite que nous avions appelé "Ne pas-se concentrer-sur-BDD-outils-de se Comporter". J'ai peut-être fortement impliqués dans d'autres bits de la BDD. Plus Dan le Nord va m'acheter une pinte si je peux obtenir ce message, il n'est donc pas exactement un avis impartial.

Peu importe -, les conversations déjà. C'est juste des gens. Allez parler.

Answer 2

Je ne sais pas si il y a une telle chose, à proprement parler, comme un "BDD de test". BDD est une philosophie qui suggère que la meilleure façon d'interagir et de collaborer avec les intervenants afin de compléter un projet complexe. Il n'est pas directement faire de toutes les prescriptions pour la meilleure façon d'écrire des tests. En d'autres termes, vous aurez probablement encore ont tous les types de tests (y compris les tests d'acceptation) en vertu d'un BDD-philosophie du projet.

Quand vous entendez parler de "BDD cadres", le haut-parleur signifie généralement un cadre pour la rédaction de tous vos habituels types de tests, mais avec une BDD de torsion. Par exemple, dans RSpec, vous avez encore écrire des tests unitaires; il suffit d'ajouter la BDD de la saveur à eux.

Answer 3

Je tiens à faire une distinction entre les "specs" et "tests".

Si je suis couvrant une méthode appelée GetAverage(IEnumerable<int> numbers), je vais écrire plus ou moins standard de test de l'unité.

Si je suis couvrant une méthode appelée CalculateSalesTax(decimal amount, State state, Municipality municipality), je suis toujours en cours d'écriture de l'unité de test, mais je vais l'appeler un cahier des charges, parce que je vais le changer (1) pour vérifier le comportement de la routine, et (2) parce que le test lui-même permettra de documenter à la fois la routine et de ses critères d'acceptation.

Considérer:

[TestFixture]
public class When_told_to_calculate_sales_tax_for_a_given_state_and_municipality() // the name defines the context
{
    // set up mocks and expected behaviour
    StateSalesTaxWebService stateService 
    	= the_dependency<IStateSalesTaxWebService>;
    MunicipalSurchargesWebService municipalService 
    	= the_dependency<IMunicipalSurchargesWebService>;

   stateService.Stub(x => x.GetTaxRate(State.Florida))
    	.Return(0.6);
    municipalService.Stub(x => x.GetSurchargeRate(Municipality.OrangeCounty))
    	.Return(0.05);

    // run what's being tested
    decimal result = new SalesTaxCalculator().CalculateSalesTax
    	(10m, State.Florida, Municipality.OrangeCounty);

    // verify the expected behaviour (these are the specifications)
    [Test]
    public void should_check_the_state_sales_tax_rate()
    {
    	stateService.was_told_to(x => x.GetTaxRate(State.Florida)); // extension methods wrap assertions
    }

    [Test]
    public void should_check_the_municipal_surcharge_rate()
    {
    	municipalService.was_told_to(x => x.GetSurchargeRate(Municipality.OrangeCounty));
    }

    [Test]
    public void should_return_the_correct_sales_tax_amount()
    {
    	result.should_be_equal_to(10.65m);
    }
}

Answer 4

JBehave (et NBehave récemment ajouté la même support) travailler avec des tests réguliers des fichiers afin de bien que de nombreux autres cadres d'ajouter "BDD goût tounit tests", le texte du comportement fondé sur les spécifications/exemples créés avec JBehave sont adaptés pour les tests d'acceptation. Et non, vous n'avez pas besoin de fitnesse pour que.

Pour avoir une idée de comment cela fonctionne, je suggère JBehaves 2min tutoriel.

Answer 5

Tandis que la BDD est plus grand que le champ d'application de juste des tests, il y a en effet BDD tests. Ces tests sont des Tests Unitaires qui suivent la BDD de la langue.

Compte tenu de certaines contexte initial (les données), Lorsqu'un événement se produit, puis de s'assurer de certains résultats.

Il y a quelques bonnes BDD cadres disponibles en fonction de votre langue de préférence. JBehave pour Java RSpec pour Ruby NBehave pour .NET