Headless browsers vs Real browsers

Hi guys, I have noticed that many developers doesn’t know the purpose of the headless browsers and when you can consider to use them. Everything depends of your project and what is the purpose of your tests.

Headless browser is like any other regular browser, but without the GUI (Graphical User Interface). The networking component, javascript interpreter, rendering and layout engines are still present. They are particularly useful for testing web pages as they are able to render and understand HTML the same way a browser would, including styling elements such as page layout, colour, font selection and execution of JavaScript and AJAX which are usually not available when using other testing methods.


You can use headless browser for:

  • Test automation in web applications (Best performance as you don’t have a GUI).
  • Taking screenshots of web pages.
  • Running automated tests for JavaScript libraries.
  • Scraping web sites for data.
  • Automating interaction of web pages.
  • Perform DDOS attacks on web sites.
  • Increase advertisement impressions.
  • Automate web sites in unintended ways e.g. for Credential stuffing.


Headless browsers became a known technology back in 2009 when Google revealed it was opened to using one to parse and index AJAX-based websites.

Headless browsers have been known to be used in DDOS attacks, brute-force attacks, and also for falsely increasing ad revenue by faking page loads and user interactions.


Why not to use them:

  • The gain in the speed is not that big compared with real browsers, depending of how many tests you have.
  • Hard to debug.
  • It is not a real browser, so in the end, it is not the same experience your users have.
  • Headless browser can have issues of its own that do not show up in other browsers (a bug found using a headless browser like PhantomJS may actually not be a bug).



  • Speed vs Consistency.
  • More specific code vs more general code.


Hope I have helped you guys to understand when it is possible to use them and when it is not, since it depends of your project and your requirements. You can judge what is the best option for your project in the moment.

Thank you guys, see you later !










Real vs Headless Browsers for Automated Acceptance Tests


Hooks vs Backgrounds (Cucumber)

Sometimes you need some pre conditions to run your scenario or a group of scenarios sharing the same steps repeatedly. You can use background or hooks to setup these conditions. How to know what is the best to use ? Well, depends of the case. So today, I will give some examples with best practices when you should use background and when you should use hooks.

Step definition files have a corresponding method available in the before(condition) do . . .method, which has however a matching after(condition) do . . . method as well.


Use Background only to setup a pre-condition that the user needs to know


If it is not a trivial information to the user, set it up in the implementation (hooks), not in the test steps. Remember feature files should focus on What, and not How. These should be high level steps. We want to keep this simple. So, for this reason you avoid give too many details like this type of steps: “When I press the button”.


When using hooks


You can use hooks to run before/after each scenario, a group of scenarios according to the tags, all the scenarios in a feature or all the scenarios of your project. They will run before the first step of your scenario, like the background, but it won’t need any step in your feature file.


@Before and @After each scenario

Similar to JUnit @Before and @After tagging a method with either of these will cause the method to run before or after each scenario runs. Common functionality like starting or stop browsers are nice to place in these hooks. They reduce the number of common test steps in each scenario. Before hooks will be run before the first step of each scenario. They will run in the same order of which they are registered. After hooks will be run after the last step of each scenario, even when there are failing, undefined, pending or skipped steps.

You may want to finish the tests after the first failure (could be useful in some cases like Continuous Integration when fast feedback is important), for those cases add the command (ruby) in your hook:

  Cucumber.wants_to_quit = true if s.failed?



You have also the possibility to create an after step hook and add for example a take screenshot action. This hook will run after each step of you scenario and you can also filter for certain scenarios using tags. This is only available for Ruby language at the moment, not for Java.



Around hooks will run “around” a scenario. This can be used to wrap the execution of a scenario in a block. The Around hook receives a scenario object and a block (Proc) object. The scenario will be executed when you invoke block.call.

The following example (ruby) will cause scenarios tagged with @fast to fail if the execution takes longer than 0.5 seconds:

Around('@fast') do |scenario, block|
  Timeout.timeout(0.5) do


Tagged hooks

You can filter what are the scenarios that will run this hook every time before start the scenario or after the scenario ends. The condition which enables the before/after block is the tag (false or nil). Tagged hooks can have multiple tags, and follow similar tagging AND/OR rules that the runner does. You can OR and AND tags in much the same way as you can when running Cucumber from the command line.
e.x. @Before(‘@mobile’, ‘˜@login’) for tests needing a mobile browser launched and are not tagged as login

e.x. @Before(‘@mobile, ˜@login’) for tests needing a mobile browser launched or are not tagged as login


@Before all scenarios

If you have a hook you only want to run once before all the scenarios, use a global variable. Example (ruby):

Before do 
  $dunit ||= false # define a variable before we can reference its value
  return $dunit if $dunit                  # bail if $dunit TRUE
  step "run the really slow log in method" # otherwise do it.
  $dunit = true                            # don't do it again.



You may also provide an AfterConfiguration hook that will be run after Cucumber has been configured. This hook will run only once; after support has been loaded but before features are loaded. You can use this hook to extend Cucumber, for example you could affect how features are loaded or register custom formatters programatically.



When using background


Short Backgrounds

When using background keep it as short as possible. These steps won’t be written out each time the user reads the scenario, so it’s best to have something simple that the user can remember while reading through your feature file.


Vigorous Backgrounds

Similar to the above, since these steps won’t be listed with each scenario, the more vivid, the test step is, the easier time the user will have remembering it.


Short Feature files

It’s best to keep these feature files smaller, so that the Background information is more readily available. The general rule of thumb is to keep the file small enough to still see the Background test steps at the top of page when reading any scenario.


These two methods are powerful tools, but be aware to not use them excessively.






Open different browsers with C# and Selenium

Hey guys, I am going to post some snippets to run a test in different browsers with C# and selenium.


using System;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using OpenQA.Selenium.Firefox;
using OpenQA.Selenium.IE;
using OpenQA.Selenium.PhantomJS;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using NUnit.Framework;
using OpenQA.Selenium.Support.PageObjects;
using Assert = NUnit.Framework.Assert;


Driver Utils class: 

Just the beginning of the class declaring the WebDriver and the TxtSearch field, which will be used for all the below functions to open a specific browser.

namespace Helpers
 public class DriverUtils
 IWebDriver webDriver;

 //Declaring search element
 [FindsBy(How = How.Name, Using = "q")]
 public IWebElement TxtSearch { get; set; }


Open Chrome:

 public void Chrome_Browser()
 webDriver = new ChromeDriver();


Open Chrome Mobile Emulator:

 public void Chrome_Mobile_Emulator_Browser()
 ChromeOptions chromeCapabilities = new ChromeOptions();
 chromeCapabilities.EnableMobileEmulation("Google Nexus 5");
 webDriver = new ChromeDriver(chromeCapabilities);


Open Chrome Capabilities starts Maximized:

 public void Chrome_Capabiblities_Browser()
 ChromeOptions chromeCapabilities = new ChromeOptions();
 webDriver = new ChromeDriver(chromeCapabilities);


Open Firefox:

 public void Firefox_Browser()
 webDriver = new FirefoxDriver();


Open Firefox with Profile:

 public void Firefox_Profile_Browser()
 var profile = new FirefoxProfile();
 webDriver = new FirefoxDriver(profile);


Open PhantomJS:

 public void PhantomJS_Browser()
 webDriver = new PhantomJSDriver();


Open PhantomJS with Capabilities:

 public void PhantomJS_Capabilities_Browser()
 var options = new PhantomJSOptions();
"Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/40.0.2214.94 Safari/537.36");
 webDriver = new PhantomJSDriver(options);


Open Internet Explorer:

 public void IE_Browser()
 webDriver = new InternetExplorerDriver();


Open Internet Explorer with Options:

 public void IE_Options_Browser()
 var options = new InternetExplorerOptions
 IgnoreZoomLevel = true 

 webDriver = new InternetExplorerDriver(options);


Assert Search Element is Displayed:

public void AssertSearchElement()

 PageFactory.InitElements(webDriver, this);


Close/Quit Browser and driver function:

public void CloseDriver(IWebDriver driver)


See you again in the end of this week, hopefully I will have the complete flow for a BDD scenario with C# and Selenium.