Archive

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.

Like this:

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.

Code:

public class Funcionario {

private double salario;

private String nome;

public String getNome() {

returnnome;

}

public void setNome(String nome) {

this.nome = nome;

}

public void setSalario(double salario) {

this.salario = salario;

}

public double getSalario() {

returnsalario;

}

}

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.

Code:

public class TestaFuncionario {

public static void main(String[] args) {

Funcionario funcionario = newFuncionario();

funcionario.setNome("Thiago");

funcionario.setSalario(2500);

System.out.println(funcionario.getNome());

System.out.println(funcionario.getSalario());

}

}

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

Like this:

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:

publicclassCustomerLookupTest extendsTestCase {

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