Archive for August, 2013

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.


– (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.


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, acesso em 26/02/2010.
NORTH, D. What’s In a Story? 2007. Disponível em, 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,
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.

Understanding encapsulation

August 8, 2013 2 comments

This technique is used to hide an idea, when you don’t want expose the inter details to the users.

As a more technical example we can describe what happens in a sales system, where we have records of employees, users, managers, clients, and other products. If happens a problem in the user, only this sector will be fixed and does not affect the others.

In a process of encapsulating the attributes of the classes are kind of private. To access these types of modifiers, you must create getters and setters methods.

The methods setters are used to change the information of a property of an object, and getters to return the value of this property.

See an example of encapsulation, in Listing 2 creates the attributes private (private) and is carried out the process of generating getters and setters methods.



public class Funcionario {
    private double salario;
    private String nome;
    public String getNome() {
        return nome;
    public void setNome(String nome) {
        this.nome = nome;
    public void setSalario(double salario) {
        this.salario = salario;
    public double getSalario() {
        return salario;

So, is instantiated class “Employee”, where the variable reference is used to invoke methods setters, reporting any data. In the end, the getters is used within the “System.out.println” to output the results that were passed in the methods setters.


public class TestaFuncionario {
    public static void main(String[] args) {
        Funcionario funcionario = new Funcionario();

This is easy and helps you avoid pass a lot of parameters in methods, classes and functions.

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:

- 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.”



%d bloggers like this: