BDD in resume

Behavior Driven Development is a term very used in actual days…

Developers, testers, managers talking about BDD. Frequently we heard complains about BDD like:

 

– The client don’t mind about the tests.

Make all sense that because the client wants that his software is finished and working. Unfortunately, the word test brings a negative image. But we talking about BDD, which is a development by behaviour and it isn’t anything with tests. Testing is something that you don’t can do while there isn’t software. Testing means to verify and BDD we are specifying before of anything.

BDD is an activity of design, where you build parts of a function according with the expected behaviour. In BDD we go out of the vision of tests and enter in the perspective oriented by specifications, what means that this complain born with a bad colocation.

 

– The client don’t want write the scenarios.

This is the second more used complain. The cliente should write the scenarios by himself. If the client write the scenarios, he won’t benefit himself of cognitive diversity. This diversity only appears in groups heterogeneous that work together.

The client needs the advices of engineers who knows the technical aspects of the problem that he is trying to resolve. He needs of paradigm of an QA Analyst, which will help with the create of scenarios that anyone though before. Otherwise, the solution that the client though can be more complex than the solution needs be.

 

– The client needs interact directly with the tool.

This isn’t the idea. What he really need to do is to provide informations to the team about the problem that he wants resolve.

– You can achieve the same result without a specific language of domain(DSL)

To finalize, the highlight idea behind the BDD is the focus in prevent fails of communication. This means have all in team  communicating in a frequently form, better and based in real examples – not only in abstraction and imperatives requirements.

Tools of BDD are only complements to this complete agile methodology.

You can read some books like:

– Specification by example – Gojko Adzic;

– TheRSpec Book – David Chelimsky;

– Gojko on BDD: Busting the Myths;

 

Bye , bye !

Understanding BDD – Behavior Driven Development

Hello guys,

I will explain what is BDD in a simple way. It’s a development technique, who extends quality assurance, design, requirements and validations. The BDD is divided by cycles, the cycle outside-in.

1. Scenario: It’s is a specific functionality, very clear and exact.

2. Specification for the scenario: Write a specification that explains for steps how the scenario will work (for users).

3. Specification of unity: Write a specification that explains how the scenario will works, but this time the specification will be for development, in some class or function.

4. Make the specification of unity works: This artefact of software should be done of a minimum and simple way. The most simple way for the specification work.

5. Refactor:  The specification that was made simple, will be re-structured for the new design.

6. Refactor: This re-structure will work in a different way , of the implementation (artifacts of software) to the requirements (user), in this level, new functions and design can be introduced.

Structure:

– (Given) that specify the pre-conditions for the occurrence of the action of the interest scene;
– (When), whose function is to specify the events that must occur to the scenario to run;
– (Then) that specify the expectations regarding the results of the execution of events in the scenario.

References:

ASTELS, D. Test-Driven Development: A Practical Guide. Upper Saddle River, NJ: Pearson Education, 2003.
BAIN, S. Emergent Design: The Evolutionary Nature of Professional Software Development. New York: Addison-Wesley, 2008.
BECK, K. Test-Driven Development By Example. New York: Addison-Wesley, 2002.
BECK, K. Implementation Patterns. New York: Addison-Wesley, 2007.
BECK, K.; ANDRES, C. Extreme Programming Explained: Embrace Change. 2. ed. New York: Addision-Wesley, 2004.
BOEHM, B. Software Engineering Economics. New York: Prentice-Hall, 1981.
CHELIMSKY, D. et al. The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends. Dallas: The Pragmatic Bookshelf, 2010.
COHN, M. User Stories Applied: For Agile Software Development. New York: Addison-Wesley, 2004.
CRISPIN, L. Driving Software Quality: How Test-Driven Development Impacts Software Quality. IEEE Software, IEEE, v. 23, n. 6, p. 70, 2006.
ERDOGMUS, H.; MORISIO, M.; TORCHIANO, M. On the Effectiveness of Test-First Approach to Programming. IEEE Transactions on Software Engineering, IEEE, v. 31, n. 3, p. 226, 2005.
EVANS, E. Domain-Driven Design: Tackling Complexity in the Heart of Software. New York: Addison-Wesley, 2004.
FOWLER, M. et al. Refactoring: Improving the Design of Existing Code. New York: Addison-Wesley, 1999.
FREEMAN, S.; PRYCE, N. Growing Object-Oriented Software, Guided By Tests. New York: Addison-Wesley, 2009.
JANZEN, D. Software Architecture Improvement Through Test-Driven Development. In: Proceedings of the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages and Applications. [S.l.: s.n.], 2005.
JANZEN, D.; SAIEDIAN, H. On the Influence of Test-Driven Development on Software Design. In: Proceedings of the 19th Conference on Software Engineering Education & Training. North Shore Oahu, HI: [s.n.], 2006. p. 141–148.
JEFFRIES, R.; MELNIK, G. TDD: The Art of Fearless Programming. IEEE Software, IEEE, v. 24, n. 3, p. 24, 2007.
KOSKELA, L. Test Driven: TDD and Acceptance TDD for Java Developers. New York: Manning, 2007.
MARTIN, R. Clean Code: A Handbook of Agile Software Craftsmanship. New York: Prentice-Hall, 2008.
MESZAROS, G. xUnit Patterns: Refactoring Test Code. New York: Addison-Wesley, 2007.
NORTH, D. Introducing Behaviour-Driven Development. 2006. Disponível em http://dannorth.net/introducing-bdd, acesso em 26/02/2010.
NORTH, D. What’s In a Story? 2007. Disponível em http://dannorth.net/whats-in-a-story, acesso em 01/03/2010.
PRESSMAN, R. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill, 2006.
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Pearson Addison-Wesley,
2007.
WILLIAMS, L.; MAXIMILIEN, M.; VOUK, M. Test-Driven Development as a Defect Reduction Practice. In: Proceedings of the 14th International Symposium on Software
Reliability Engineering
. [S.l.: s.n.], 2003.

Introducing a BDD

Hello, my friends ! Look what I’ve found. A simple text about tests in BDD (Behavior Driven Development). It is very interesting and usefully.

 

“[…]

Test method names should be sentences

My first “Aha!” moment occurred as I was being shown a deceptively simple utility called agiledox, written by my colleague, Chris Stevenson. It takes a JUnit test class and prints out the method names as plain sentences, so a test case that looks like this:

public class CustomerLookupTest extends TestCase {
    testFindsCustomerById() {
        ...
    }
    testFailsForDuplicateCustomers() {
        ...
    }
    ...
}

renders something like this:

CustomerLookup
- finds customer by id
- fails for duplicate customers
- ...

The word “test” is stripped from both the class name and the method names, and the camel-case method name is converted into regular text. That’s all it does, but its effect is amazing.

Developers discovered it could do at least some of their documentation for them, so they started to write test methods that were real sentences. What’s more, they found that when they wrote the method name in the language of the business domain,the generated documents made sense to business users, analysts, and testers.”

 

Font: http://dannorth.net/introducing-bdd/