Archive for February, 2014

What is TDD ?

February 24, 2014 1 comment

The first step is to quickly add a test, basically just enough code to fail.  Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail.  You then update your functional code to make it pass the new tests.  The fourth step is to run your tests again.  If they fail you need to update your functional code and retest.  Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed, turning TFD into TDD).


I like to describe TDD with this simple formula:

   TDD = Refactoring + TFD.

TDD completely turns traditional development around. When you first go to implement a new feature, the first question that you ask is whether the existing design is the best design possible that enables you to implement that functionality.  If so, you proceed via a TFD approach.  If not, you refactor it locally to change the portion of the design affected by the new feature, enabling you to add that feature as easy as possible.  As a result you will always be improving the quality of your design, thereby making it easier to work with in the future.

Instead of writing functional code first and then your testing code as an afterthought, if you write it at all, you instead write your test code before your functional code.   Furthermore, you do so in very small steps – one test and a small bit of corresponding functional code at a time.   A programmer taking a TDD approach refuses to write a new function until there is first a test that fails because that function isn’t present.  In fact, they refuse to add even a single line of code until a test exists for it.  Once the test is in place they then do the work required to ensure that the test suite now passes (your new code may break several existing tests as well as the new one).   This sounds simple in principle, but when you are first learning to take a TDD approach it proves require great discipline because it is easy to “slip” and write functional code without first writing a new test.  One of the advantages of pair programming is that your pair helps you to stay on track.

There are two levels of TDD:

  1. Acceptance TDD (ATDD).  With ATDD you write a single acceptance test, or behavioral specification depending on your preferred terminology, and then just enough production functionality/code to fulfill that test.  The goal of ATDD is to specify detailed, executable requirements for your solution on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
  2. Developer TDD. With developer TDD you write a single developer test, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test.  The goal of developer TDD is to specify a detailed, executable design for your solution on a JIT basis.  Developer TDD is often simply called TDD.


Note that Figure 2 assumes that you’re doing both, although it is possible to do either one without the other.  In fact, some teams will do developer TDD without doing ATDD, see survey results below, although if you’re doing ATDD then it’s pretty much certain you’re also doing developer TDD.  The challenge is that both forms of TDD require practitioners to have technical testing skills, skills that many requirement professionals often don’t have (yet another reason why generalizing specialists are preferable to specialists).

An underlying assumption of TDD is that you have a testing framework available to you.  For acceptance TDD people will use tools such as Fitnesse or RSpec and for developer TDD agile software developers often use the xUnit family of open source tools, such as JUnit or VBUnit, although commercial tools are also viable options.  Without such tools TDD is virtually impossible.  Figure 3 presents a UML state chart diagram for how people typically work with such tools.  This diagram was suggested to me by Keith Ray.


Kent Beck, who popularized TDD in eXtreme Programming (XP) (Beck 2000), defines two simple rules for TDD (Beck 2003).  First, you should write new business code only when an automated test has failed.  Second, you should eliminate any duplication that you find.  Beck explains how these two simple rules generate complex individual and group behaviour:

You develop organically, with the running code providing feedback between decisions.

  • You write your own tests because you can’t wait 20 times per day for someone else to write them for you.
  • Your development environment must provide rapid response to small changes (e.g you need a fast compiler and regression test suite).
  • Your designs must consist of highly cohesive, loosely coupled components (e.g. your design is highly normalized) to make testing easier (this also makes evolution and maintenance of your system easier too).

For developers, the implication is that they need to learn how to write effective unit tests.  Beck’s experience is that good unit tests:

  • Run fast (they have short setups, run times, and break downs).
  • Run in isolation (you should be able to reorder them).
  • Use data that makes them easy to read and to understand.
  • Use real data (e.g. copies of production data) when they need to.
  • Represent one step towards your overall goal.




Function of Screenshot of the page

February 18, 2014 1 comment

Hi Guys !

Today I will show the code to take a screenshot of the page, when occur a exception and when you have to take a evidence.

Look my functions:


I have added some things that I used a lot here. If you have any questions, just write bellow !

Bye bye 🙂

2 Ways to make a Repository of WebElements WebDriver

February 11, 2014 Leave a comment

Hello my friends 🙂

I hope that you are ok !! I will post today a technique to save the webelements in one file, or in various files but more organized and with this is easier to do maintenance when the website have some xpath, id, classname, tagname or link modified. I used this repository on xml in Bovespa. In this post I will show 2 ways to do this repository:


  • First – Create a class with the objects:

–  Create the project, you may follow the structure bellow:


– Create a  class under testObjects Package (

– Create a  class under testScripts Package  (

– Open your and write the code :
Don’t forget the package of this class is testObjects, so put in the first line:
package testObjects;


– After this, open TestPageLogin.Java and write :


Don’t forget the package of this class is testScripts, so put in the first line:

package testScripts;


  • Second – Create a OR file (You can use XML too)

– Create the project, you may follow the structure bellow:


– Create a text file with the Extension as .OR  under the object Repository Package (in this case: com.sagara.objectrepository)


– Create a java class under test Pages package (in this case: com.sagara.testPages)


– Open your .OR file and write the objects informations with a structure like this:



– Open your class Java and write the below code to get the objects information’s from the OR file and use it:


I hope that I has helped, if you have some doubts just let your comment 🙂

Bye guys !


Cucumber Steps and Codes in calabash-ios

February 4, 2014 Leave a comment

Hey guys, this is my first video !
Well… I know that it is in portuguese and there is some gaps but I think it will be helpfull 🙂

Bye !

%d bloggers like this: