Book Image

Robot Framework Test Automation

By : Sumit Bisht
Book Image

Robot Framework Test Automation

By: Sumit Bisht

Overview of this book

Testing has traditionally been a part of software development, and has always involved a lot of manual effort. It can be automated with Robot Framework, which offers numerous benefits from cost saving to increased quality assurance in the software delivery. This book will help you to start designing test suites and Automated Acceptance Tests. Helping you to get started with automating acceptance tests, this book will provide a detailed overview of acceptance test management practices and principles. You will also be introduced to advanced techniques that you can use to customize the test suite, along with helpful tips and tricks to extend and leverage it in a wide variety of scenarios. Starting with a detailed explanation of the need for automated acceptance test driven development, this guide will help you with an empty test project creation and execution for proof of concept, and validation of installation. This book will also cover the Robot Framework in detail, and will help you test desktop applications using Java Swing. You will gain an in-depth knowledge of tricky activities, such as setting up a test environment and using it with Selenium. You will also learn about other popular libraries, and how to test network protocols, web services, and databases. This book will cover the entire Robot Framework with real- world practical material to make its content informative and interesting. By the end of this book you will be able to write acceptance tests for desktop and web applications, as well as know how to extend acceptance testing in other scenarios that are commonly devoid of tests, and present the results appropriately.
Table of Contents (12 chapters)

Behavior-driven development


Despite the obvious benefits of automated acceptance tests, in practice, even amongst experienced XP and TDD teams, it's rarely done, or done well. One of the reasons is that finding a stakeholder with the technical ability, interest, and patience to sit in front of a computer writing pure code for even a DSL like gerkin or RSpec is hard. Consider the following rspec test present in WEBrick (an HTTP server in Ruby commonly used in development):

  should "be a WEBrick" do 
    GET("/test") 
    status.should.equal 200 
    response["SERVER_SOFTWARE"].should =~ /WEBrick/ 
    response["HTTP_VERSION"].should.equal "HTTP/1.1" 
    response["SERVER_PROTOCOL"].should.equal "HTTP/1.1" 
    response["SERVER_PORT"].should.equal "9202" 
    response["SERVER_NAME"].should.equal "127.0.0.1" 
  end

This example observes the behavior that is based on the response from the server, from this it can be concluded that the server is a WEBrick server or not.

However, at time this may...