Background

• The Encyclopedio of Life (EOL) is an ROR open source project to create a free, online reference source and database for every one of the 1.8 million species that are named and known on this planet.

• The Encyclopedio of Life (EOL) is an ROR open source project to create a free, online reference source and database for every one of the 1.8 million species that are named and known on this planet.

• Automated tests decrease the cost of releases dramatically and ensure the integrity of the data, code, and visual representation.

• The goal of this project is to develop an acceptance testing framework that can check all the functionalities of EOL website.

• The ultimate goal of this project is to extend the framework to be general enough to check any given website, simply by changing the configuration and defining new test suits.

BDD

• Behavior driven development (BDD) is an agile software development technique that encourages collaboration between developers, QA, and non-technical or business participants in a software project.

• BDD focuses on the application behavior rather than coding. The developers write test cases in a natural language such as English, that non-programmers can read and understand, which create a bridge between developers and non-technical people.

Architecture• Environment configuration files are the files that

are used to customize the environment variables, which enables this project to be a generic testing framework that can be used to test any website.

• YAML was chosen as the preferred file format for configuration files because of its ease of use and robust integration with Ruby.

• Feature and step definitions files are the specification testing files that validate the system functionality against the specifications.

• Support helper files are the system helper files that are used to parse the customized environment variables, path, and selectors from the environment configuration files.

Cucumber• It started as a tool for Ruby, but now supports a

wide variety of platforms, e.g. Java, .NET.

• There are 2 kinds of important files in Cucumber: Feature file and step definition files, to validate the system functionality against the specifications.

• Feature file ends with .feature, step definition files are ruby files.

Feature File

• Cucumber feature files are plain-text files that can be written in over 20 languages.

• A feature file describes a or a part of a feature with expected outcomes. Cucumber uses these files to validate the system functionality against the specifications. It makes it absolutely clear what the system is expected to do and helps to avoid any misunderstanding and ambiguity. It also makes it possible for an automation tool to check whether the system works according to the specification.

Feature File• A feature file allows for a short description in a

header, which describes the intention of the feature. The header should give the reader a context to understand the rest of the file, it usually described in the user story format: to describe a feature, name the stakeholder, the benefit and the intended solution.

• Each scenario follows by a title providing the reader the context required to understand the example described by the scenario. Each scenario is described by one or more steps.

Step definition file.

• Step definition file is a ruby file, like method or function definition.

• They tell Cucumber what to do when interpreting a particular step.

• Steps can be reused in many scenarios.

Capybara

• Capybara is an acceptance testing framework for the rack based (Rails, Merb) application. It simulates how a user interact with the application.

• Can be used with Cucumber, Rspec, RubyOnRails, or other Rack application.

Selenium• By default, Capybara uses the :rack_test

driver, which is fast but does not support JavaScript.

• So in this project, we set up the default driver: Selenium, which supports Javascript and AJAX tests.

Collaboration

• Due to the distributed characteristic of the team, it is critical that how effective we collaborate and manage our work.

• We use Distributed Version Control – GIT, to manage the code, store the repository in GitHub.

Why Git not SVN?

• nearly every operation is done off data on the local disk. fast and can be done offline

• does not have a single point of failure. Every member working on the project has a full backup of the project data, losing the collaboration servers is a minor inconvenience at best.

• branches operations. Create and merge branches