JavaScript Patterns: IIEF - Immediately Invoked Function Expression

The "createWorker" function is interesting. Because it creates in JavaScript what is known as a scope. 

The local variables that we've created inside the function, like "workCount", "task1" and "task2", they are only visible inside the function itself.

We can have function definitions nested inside of other functions in JavaScript. That’s how "task1" can point to a function that is inside of another function that we assigned to "createWorker".

This is great because "task1" can't be visible outside "createWorker". If we try invoke "task1" from the “worker” object.

We’ll get an error “undefined is not a function” on line 22.

That means something like “I don’t know what task1 is. I’ve got undefined for that and you decided to invoke it. That’s not gonna work”.

The only way we can invoke “task1” is because “createWorker” explicitly reference task1 in an object that is returned to the outside world.

But “task1” itself is inside the scope of “createWorker” and it’s not visible to the outside.

And these variables that we have outside of this function definition, including the variable “createWorker” and the variable “worker”, they are also outside the scope and unfortunately it is the global scope.

They are global variables because they are defined outside any other code, or any other function. If you are doing Software Development for a long time, you’ve probably heard that global variables are bad.

They easily become a source of confusion and bugs. But in JavaScript, global variable are beyond bad. They are evil.

Because JavaScript is a dynamically typed language, it’s very easy to overwrite a global variable defined by someone else and vice-versa. So we should try to avoid globals at all cost.

Is there a way to define all the code that we have, executing that code and achieving the same output without create any global variable?

The answer is yes. What if outside of “createWorker” we define a function called “program”, and program is going to wrap up not just “createWorker”, but also the code where we instantiate a “worker” and call “job1” and “job2”.

Right now, we only have one global variable called “program”.

But how do I get to zero global variables?

What if instead of declaring a variable “program” which will be global. What if we just took this function and at the very bottom of the function definition we just add it invoke itself.

There’s one little problem here. JavaScript doesn't particularly like this syntax.

It doesn't like to have an anonymous function that invokes itself. What we have to do is apply an extra left parenthesis before the keyword function and then have a corresponding close parenthesis at the end before the semi colon.

And what we have built is something called in JavaScript circles an Immediately Invoked Function Expression (IIFE).

It’s a function that has code inside that immediately invokes itself. Because all of that code is inside a function we're not creating any global variables.

All the variables that have been defined are local variables inside of that IIFE.

We should use IIFE to avoid create any global variables. A lot of JavaScript libraries use IIFE to control the scope of the variables, to build modules to provide encapsulation and most of all to avoid global variables.

JavaScript Patterns: Revealing Module Pattern

A good way of organizing our code is creating modules. A module can expose methods and data. But sometimes we don’t want to expose everything to the outside world.

In C# we can define our method or properties with access modifiers. And in JavaScript? Is there a way of doing this? The answer is yes.

Let’s see an example:

We start by creating a variable called worker and we will invoke a function called CreateWorker.

Once we will have the worker, we would like to perform different jobs (job1, job2).

And it’s not really important what the specific jobs are. Job1 could be calling a web service. Job2 could be applying a template to the data returned from the web service.

We are not really concerned about these details at this point. We will be focused in how we create this worker object that has 2 methods on it (job1 and job2).

We will create another variable called “createWorker”, this variable will point to a function that will return an object. That object would contain job1 and job2.

We could implement those functions in line, but we don’t want to do that. Instead we will create another to variables called "task1" and "task2" that will point to our functions.

This is how we expose "task1" and "task2" from our model.

The object literal syntax will allow us to expose those functions. We can say that "job1" points to "task1" and "job2" points to "task2". 

The top part is our private implementation details. We can even have private functions that would not be exposed from this object.

In the bottom part, when we return this object is where we define our public API. Here’s an object that have two methods, job1 and job2. No one really needs to know what is inside. But if we execute this code we’ll see that we are executing task1 and task2.

This is called “Revealing Module Pattern”. It’s called Module, because what we’ve done was encapsulate some code inside of a function. The general meaning of module in Computer Science and Software Development is “Collection of components or features that you can put together to perform some useful work”. We are creating a module in JavaScript by creating a function. Inside of that function we will build out some things that we can use and expose to the outside world.

And we can even have some private implementation details. If we create a variable called workCount that counts the number of times that task1 and task2 have been invoked.

That’s not something we want to expose to the outside world and allow them to manipulate it.

It’s just something that we want to use as an internal implementation detail, and perhaps each time this methods are invoked we will increment workCount and we will also print out the current value of workCount inside of each task.

If we run our code.

We can see its incrementing “workCount”. This is a good way to organise and isolate our code exposing only what needs to be exposed to the outside world.

JavaScript Patterns: Functions as abstractions

How can we use functions to create abstractions?

We will create a variable called “work” and we want that variable to point to a function.

The purpose of this function is to abstract the way some sort of operation needs to be performed.

We need to do some work and we want to wrap that code inside of a function and assign it to a variable called “work”.

And the only work we’ll do here is something really simple.

“Working hard...” should appear in our console when we run this program.

And it works. So now let’s raise the level of abstraction.

Let’s create another variable called “doWork”. This one is going to be a function and it will take a parameter called “f”. “doWork” expects that “f” will be another function. Something that will be invoked.

If we invoke “doWork” and we pass in our “work” variable that happens to point to a function. All of this should still work and we should see “Working hard...” in our console.

Why we are doing this?
Why is that useful?
Why we don’t call the function “work” directly? Instead of creating another function to invoke “work”.

The all idea here is to provide some abstraction. Maybe “doWork” represents some routine that can add retry logic or that can add value perhaps by logging.

Log when “work” starts, when “work” ends, or even log errors while executing “work”.

This is just a common pattern used in JavaScript where we use the function as the basis for an abstraction.

Functions that do work. Functions that execute work. Passing functions to other functions.

Because “doWork” is a generic function that tells us when something is started or ended and also some error handling. And we can reuse it to perform different functions.

WebRTC: The missing piece in Open Web

WebRTC stands for Web Real Time Communication. This open-source JavaScript based framework let you incorporate peer-to-peer video, audio and data communication into you application. Right in the browser without any plug-ins.

I’m very excited about the disruption WebRTC is going to have and how we’ll communicate online and on mobile.

WebRTC is in a very early stage of active development. You should expect changes to the API and implementations.

“WebRTC is a new front in the long war for an open and unencumbered web” – Brendan Eich, Mozilla CTO and inventor of JavaScript

WebRTC is undeniable on the bleeding-edge of web technologies right now.

Before WebRTC there was Macromedia Flash Communication Server MX (FCS), released way back in 2002.
Later when Adobe acquired Macromedia and their flash ecosystem. FCS was renamed Flash Media Server and it’s now called Adobe Media Server.
FCS allowed you to capture webcam video and audio and stream it right from your browser to the server and then to multiple viewers anywhere in the world. The quality was good and when they introduced tunneling to traverse firewalls it worked anywhere flash did. Which at the time was 98% of PCs. It was revolutionary.

Eventually a commercial competitor Wowza was released in 2007 and an open-source alternative Red5 in 2010 that roughly matched the functionality of Adobe. But these came a few years later.

They open up a world of possibilities for real time communication and collaboration. But unfortunately solutions like FCS have a single server license over 3000 euros restricted by the number of connections.

 And over the years many developers had brilliant ideas of using this technology that were snuffed out by the cold reality of licensing cost.

This is why WebRTC will be a game changer. Because it’s open-source and essentially free. It’s bringing that sense of possibility and creativity back to real time communication.

Where did WebRTC come from? Who’s behind it?

Back in the summer of 2010, engineers from Google, Microsoft, Apple, Mozilla, Skype, Ericsson and others had an informal lunch to discuss the possibility of building a real time communication platform that would work across browsers and mobile devices without plugins.

So the IETF FTC WEB and the W3C WebRTC working groups were formed to start defining the spec.

Shorten after Google acquired a company called GLOBAL IP SOLUTIONS (GIPS) that had low level technology that powered RTC for several large customers. Including Google, Skype, AOL, Yahoo and CISCO.

Google then turned around and open-sourced those components. Added a JavaScript API and removed any audio and video codec from the spec.

This is where things got complicated. Whenever your start messing with codecs you are asking for trouble.

Long story short, there is a codec war going on. With Google wanting to use their own open source VP8 video codec and pretty much all the other stakeholders pushing for the standard H.264 codec.
H.264 is patent covered which defeats the open and free ideal of WebRTC.

Interesting twist, in October 2013, CISCO announced that it would absorb all licensing costs for H.264 coding in the future. Effectively removing this barrier to adoption as a standard.

But even with this change, Google is still holding firm.

So while Firefox is on board with CISCO with H.264. Chrome is not. So we developers are stuck in the middle. The codecs are not the only thing that is not standardized in WebRTC. But it’s getting there.

A messy little codec war isn’t enough to hold us back from creating amazing applications using WebRTC.

WebRTC democratizes Real Time Communication which has been the missing piece in the Open Web.

Ruby: Why a blood-red colored gemstone can be so attractive?

What kind of language Ruby is and what kind of problems is suitable for?

What initially attracted me to Ruby was that it's creator has a focus on helping developers to be productive and happy.
It was a refreshing attitude. As I started using the language I've found that Ruby allows me to write very clean and readable code with minimal levels of syntactic and semantic noise.
It also comes with a huge amount of useful functionality built into it's standard library.
Ruby was first released in 1995 and over the years a large ecosystem of third-party libraries and frameworks grew around it. Particularly in the web development arena.

How does ruby compare to other languages?

Ruby started to be object-oriented has it was inspired by smalltalk. There are few primitives and many things in Ruby are expressed in terms of objects and methods. Is it based on dynamic typing and duck typing.

Dynamic Typing means that a variable can refer to objects of different types during the course of program execution.
Duck Typing means that valid semantics aren't determined by the object type. Instead it's enough for the object to have the methods which the operation uses. This allows you to have polymorphism without inheritance so class hierarchy can be a lot simpler. It also give you the opportunity to write more generic code.

The flip side is that it may require more discipline from the programmers working on the code base.

In addition to object-oriented style of programming, Ruby is flexible enough to allow functional and procedural styles of programming.

Ruby has a lot of facilities for reflection. It can get a lot of information at run-time such as class methods, in-heritage hierarchies and so on...

Another aspect of Ruby is that it provides rich opportunities for meta-programming by a vary of hook methods as well as the ability to create classes and methods dynamically.

The widely used implementations of Ruby are bytecode interpreted. This can put some limitations on performance.
The official implementation is called MRI which stands for Matz's Ruby Interpreter.
Another popular implementation is JRuby which is build on top of JVM (Java Virtual Machine).
On the Mac there's another Ruby implementation called MacRuby that can perform both just in time and ahead of time compilation of Ruby code.

Creating a simple test framework in plain English, easy to use and easy to understand

Let's start off by creating our framework and then we are gonna create a Unit Testing project and that's gonna be our tests layer.

First we start by creating a new Class Library project and call it "TestFramework".

Now that we have this project, we can go ahead and create another project inside our solution and this one will contain our tests. In this case we are gonna create a "Unit Test Project" and call it "Tests".

The idea here is to separate the Test Framework from our Tests. Remember in our Architecture Diagram we said this was really important. We don't want our tests to depend on Selenium. We want the Test Framework to depend on Selenium. And the Tests to depend on our Test Framework.

So we'll never gonna add Selenium to our Tests project. We're only gonna add to our Test Framework. And we'll make our Tests depend on our Test Framework.

So let's go ahead and add that dependency. We will go to our references in Tests and add a new reference to TestFramework.

The next thing we are gonna do is to add Selenium to our TestFramework. To do that we go to references in the TestFramework project and select the option "Manage NuGet Packages..."

We'll search for "selenium". Select the packages "Selenium WebDriver" and "Selenium WebDriver Support Classes".

So now that we have our projects set up, let's go ahead and create a very simple test.
We are just gonna open up our website "http://plan2finish.net" and log in with a valid credentials (username and password) and verify that the user logged in successfully.

So we go to our UnitTest1.cs class and create a test named Can_Login_User_With_Valid_Credentials

We are gonna write this test first and then we are gonna implement the framework to make this test succeed.
This is a little bit backwards from how you might think about writing an automation framework but I found that this is the best way to do it for two reasons:

• It makes sure your API is simple and understandable.
• It make sure you don't build more framework than you need.

So we can start writing the API we want to use inside of our test. Remember we can't depend on Selenium here. We should try to write it in plain English as possible and we are not gonna ever import Selenium.

We start by creating a method Pages.LoginPage.Goto that it's gonna go to LoginPage of plan2finish.net website.
After that we are gonna create another method Pages.LoginPage.LoginUser that will receive a username and password and will insert those values in the username and password fields on the Login Page and push the Login Button.
At last we are gonna Assert that the credentials are valid by checking if we are in the MainPage and the user logged in successfully using the method Pages.MainPage.HasUserLoggedIn that receives the username.

We go ahead and add a new class Pages inside the TestFramework project.

We are gonna make this public and static. You'll find that as we are working on the framework, the way that I like to build the framework is not the way that you should build traditional code. What I mean by this, is that you typically wouldn't make everything static. But you'll find that there is this balance between simplifying the API and making the framework code itself subscribed to use some of the best practices that you would use in a regular application. A framework for testing it's a different type of application than any other type of applications. So you don't want try and build it as a standard application.

So now that we have the Pages class, we need a LoginPage class. We'll make this one static as well.

After creating the LoginPage class we need to create a Goto method inside the LoginPage class. We'll leave the implementation for later. Let's make sure we have our test class flashed out.

So we need to add a LoginUser method to LoginPage class and create a MainPage class with a HasUserLoggedIn method inside. All static.

We can now run our test. It will fail because we don't have any implementation in our methods. So next, we'll add the implementation to our methods.

Let's start by implement the Goto method and imagine a general implementation of a Browser. A general purpose browser. We could create a browser for each page, but if we did that we would be mixing the concepts a little bit. So again, I'm gonna drive this time from the framework to the deeper layers of the framework.

The simplest thing to do would be something like:

Which url would be a constant in our class. Now we need the Browser object implementation.
We'll make a static class called Browser with a Goto method. And the implementation of this Goto method is going to use Selenium. So let's give to our Browser class an instance of our webdriver and we'll set it to a new FirefoxDriver. This implementation could be more flexible to use different types of browsers, but in this case to make things simple let's use firefox only.

Now that we have the Goto implemented we need to implement the LoginUser method.
We should inspect login page in plan2finish.net and think about our page object model as we've mentioned before.

We want to have the login page model as it's own object and it should mirror the functionality that exists when the user is using this page. So for example, you can see two fields here, one for Email and other for Password. And there's also a button Login that we'll need.

So we're gonna start off by modeling the parts we need. So we can insert a email and a password and press the login button.

In order to do that we're gonna use the Page Object Model that's built in Selenium. We can't have a static page class anymore. We have to create an instantiation of the page where we can inject the information from the page and bind the elements we want to use. This will make a little bit more sense in a minute. But first we need to refactor our code a little bit.

So we need to change our LoginPage class so it can be instantiated instead of making it static.
The same with the methods inside the class.

The next thing we need to do is to implement the LoginPage in Pages as a property. Using only the getter, we don't need the setter here.

Going back to our LoginUser method, in order to login a user in the login page, we need to get those fields and button. We are gonna inspect the page and look for the better way to retrieve them.

We can get the email field, the password field and the login button by the tags ids.

• Email: id="UserName"
• Password: id="Password"
• Login Button: id="LoginButton"

We can use the Page Object Model to do this. We will create a set of properties to bind to those elements in the page.

Then we will annotate those properties with FindsBy, and we are gonna say "How" = How.Id, it will find the element by id and "Using" the id name "UserName" for the Email field. We'll do the same for the password field and login button.

Now that we've done this, if we use the page factory that's built into the Selenium support, we can automatically go to the page and select the element according to this criteria and populate the properties with references to those elements. And we can use those binded properties in our tests.

This simplifies things quite a bit here. But in order to make this to work, we have to do something special in our LoginPage instantiation.

What we are gonna parse our page through this page factory. And we need the driver from our browser, so let's make sure we can access our driver from our Browser object.

We are initialising our LoginPage and passing it through this factory that would look for the attributes we annotated in our properties.

So now we can implement our LoginUser method in our LoginPage object.

We'll do something similar to our Main Page, the page where the user would be redirected if the credentials are correct. In the same way we'll send the main page to the page factory to be parsed.

And in the MainPage object we just have to implement the HasUserLoggedIn method:

In the Main Page, there would be a hidden field with the user name, and we'll check if our user is logged in by checking this field. But first we need to create a property to bind this hidden field to our class.

And that's it, we are ready to run our test now.

So let's take a minute now to think what we've done so far and where we might go from here. If we look at our unit test, we can see that we've made them in plain English, very easy to use. Notice we are not instantiating any objects here. It's all very simple. That's why we are using static methods so much. Even dough static methods might not be something that you would use in a traditional application.
We've basically driven the framework from the test. If you read this test, you should be able to understand exactly what's going on. It should be clear as possible.
The framework might be more difficult to build because we had to figure out ways to make the framework obey this API. Because the API came first.

Now if we look at the framework. You can see that we've divided things up by the different pages. This is the Page Object Model concept. We have a LoginPage and a MainPage.
Doing this really makes it easy to understand how your tests should be written. Because it's very intuitive. You can figure out that if there's a page in the system, there's probably gonna be a class in the framework that you can use. This is really important because in many instances the developers working in the Test Framework are not the same people that are writing the tests. You may have your QA team or someone that's not skilled in development skills writing tests. And if it's very simple and straight forward they can easily maintain those tests and it makes it a lot easier for them to figure out what they need to do or what kind of functionality they need in the framework. They can basically write their tests and then a developer that's working the Test Framework can implement the functionality that they want their test to be able to do.

That's the way I recommend working and that's why we should make our tests so simple.

Shaping the perfect Page Object Model for your Automation Framework

Let's talk about the implementation details that we're going to be use when we actually go ahead and create our Automation Framework.

Within your application UI there are areas that your tests interact with. A Page Object Model simply models these as objects within the test code. This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place.

You may have heard the term Page Object Model. This is a common term in the automation community which basically refers to idea of mapping your Automation Framework model to the model of your application pages.

So your application you may have a series of different pages and those pages are going to be modeled in our framework the same way.

So as an example, if you have a login page, we are going to create a class inside of our test framework called LoginPage and it's gonna have some of the same functionality that your login page has. It's gonna be responsible to get the elements that exist on that login page. 

For example, the username field, the password field and the login button. It will manipulate those elements at the highest level possible. That's what makes a good Automation Framework.

Instead of having a method in the LoginPage class called getUsernameField or insertTextInUsernameField. We are gonna have a Login method on the LoginPage class and we'll pass the username, the password and automatically it's going to know how to insert the username and password into the correct fields and push the login button.

This is going to aid in our automation. It's where that coffee maker example comes into play. Part of this idea of the page object model is to design this high level API. You are thinking about designing your framework for your test in the same way that the user might use the real page.

You can see also that the objects of your Page Object Model don't have to necessarily map to exact pages in your application. In this diagram we have a Navigation Menu example. And maybe you have this Navigation Menu in every single page. It's a section of you application. So it's gonna map to it's own logical object in your framework and you'll have methods that your tests can call and use it just like a real user would.

And by doing it this, you make it very simple to write your tests and understand your tests.

Divide et impera - How to set up your Automation Framework

Let's look at a basic architecture example that you can use to create your Automation Framework.
If you look at this diagram here, looks fairly simple. But there're some very key things going on here.

The biggest thing that's happening is that your Test Scripts are depending on an Automation Framework and they're not depending directly on Selenium.

We are gonna have our Tests Scripts only depending on our Automation Framework that we are gonna create. And then the Automation Framework is gonna depend on Selenium.

Technically we could swap out the Selenium layer and replace it with a different type of Automation Tool besides Selenium. And just modify the connecting pieces from our Automation Framework and our Tests Scripts should still be able to run.

The goal of our Automation Framework is to support our Tests Scripts. You can also think about what concepts are related to this different layers here:

So, the Tests Scripts are gonna be focused on things like, pages in your applications, workflows. Things that are very domain specific to your application. It's actually going to share the same domain knowledge with your application.

At the Automation Framework layer we are gonna be focused on smaller pieces like the DOM (Document Object Model), things that exist in the browser. This is where we're going to be getting elements from the pages and we're going to be focused on how to manipulate pages and how to best navigate through the application.

Than at the Selenium layer we are at a very low level. It's focused on the actual HTML, the elements. It's parsing the pages. It's using the Browser API. It's at the very lowest level.

The fundamental truth about the framework architecture of automated testing

There's a lot of different ways you can build frameworks for automated testing.
The way that I'm going to suggest is a way that I've found by trying and prove it.
It's a way you can always evolve over time and a lot of people are using similar ways to this one.
This is a fundamental truth about the framework architecture of automated testing.
I highly recommend that you at least follow very closely to this approach .

Let's think about an example of Making Coffee, so you can understand what level of the API we are shooting for our automated testing framework.

This is a very important concept! A lot of people miss this and end up writing fragile tests because of not using a framework.

Everybody knows how to make coffee.
There's a couple of different ways you can make coffee.

The Low Level Approach

1. You get the coffee beans
2. You grind your beans in a grinder
3. You heat up some water
4. You put a filter inside of your cup with the coffee beans you ground before
5. You put some hot water into that filter and then what comes out is coffee

Quite a few steps here, because it's a very low level

The High Level Approach

1. You get a capsule of coffee
2. You insert the capsule into your coffee machine
3. You press a button and what comes out of your machine is coffee

Still a lot of steps here, but definitely fewer steps than the low level approach.

This is actually the level we want to write tests at. And the reason why we want to do this it's because:

• We want them to be very simple to write.
• We want them to be very maintainable 
• We want the framework to handle all the low level details

Because you don't want your tests to be complicated. You want them to be as simple as possible so they are easy to maintain, easy to understand and they don't require programmers to build them.

This is one of the key things that will determine the success of you automation framework.

Why do we need an Automation Framework?

Why should we create an automation framework?
Why all this work?
Why we just don't record our tests with Selenium IDE? This seems like an easy way to go!
Why do we have to write all this code?

There's a few reasons why recording doesn't work, but the main reason is:

Test Fragility

The major reason is Test Fragility. If we look at this simple diagram we can see that if you decided that you are just gonna record your tests and you won't gonna use some kind of a framework. Than your tests will directly depend on your application.

So what happen now, if you application changes in some way? Let say that the structure of the application changes significantly. Or even just minor little changes.

If you have a large number of tests and all those tests depend on a particular element on a page being named a certain way and that changes. All of those tests are suddenly going to break. And you will have to modify all that code in all those tests. That's really the big disadvantage of recording. Because recording is going to grab the elements by the most efficient way that it can find to grab the element instead of doing it in an abstracted way of grabbing that element. So if the element changes, as those tests break. You are copying a lot of code, when you are recording.

How can we reduce this fragility?

Now let's think about what happens, if we put an Automation Framework in place. The only modification I've made to this diagram was adding an abstraction layer. And that's what the Automation Framework is doing for you. It's primarily giving you an abstraction from the actually application.

The idea here, is that your test now depends on the Automation Framework. You are using the Automation Framework as an internal language for writing your tests. So since your tests depend on that Automation Framework. We run away from that scenario, if something changes in your application now, then you have just to update the method in your Automation Framework that manipulates that object in your application.

So let's imagine an id change, or a name of some field that you are using on an element change. Well hopefully, you've only just created one reference to it in your Automation Framework. You've abstracted the idea of how to grab that element or use that element. And so all those tests are dependent on the framework and so you've only have to change in one place. Because there's not that duplication of the dependencies on your application.

So that's the major reason why we don't want to record.

Testing your web application in parallel with multiple machines againstdifferent browsers using Selenium Grid (Part 2)

So this time we are gonna start up selenium server, but we are gonna start it up as a hub.

On my main computer (PC1), I' just gonna do the same command we done before "java -jar selenium-server-standalone-2.41.0.jar" and this time we are gonna use " -role hub" and this is gonna put this instance in hub mode.

Now there's a couple of other things we can do here. One is setting up a port, doing " -port <port_number>", that will change the port number. 
By default that's gonna be 4444. In case you have that in use you can change it. 
And you can also specify a configuration file, a JSON file in, as well a couple of other configuration options.

In most cases, this standard configuration works. So we just gonna keep things simple for now and use only "- role hub".

You can see it's lunching selenium grid server. You can tell that you are in grid mode, because it says "grid server" in this case. And you can see it's connected on port 4444.

Now once we have this up, we want to test to make sure this is actually running. So what we are gonna is open a browser and type this address "http://localhost:4444/grid/console".

And you can see it shows a page with "Grid Console", the version number and we can click "view config" to view the configuration here.

And this is the configuration for the hub, and we you'll see the details of the configuration. Some of those settings are pretty basic, like the port number, timeout. All this settings can be modified, but for the most cases the basic configuration is usually gonna work.

Now when we'll have nodes connected, we are gonna return to this console and we'll be able to see those nodes and manage those nodes. 

So, let's go ahead and create our first node.

Setting up the first node (PC1 - Windows 8)

We just have to open another command prompt and type "java -jar selenium-server-standalone-2.41.0.jar" but this time we are gonna do " -role node" and then we are gonna do " - hub" and specify where our hub is " http://localhost:4444/grid/register". 

And again here, with the node we can specify some configuration, we can set a different port. 

The port by default it's gonna be "5555".

So let's go ahead and run this:

And you can see it's lunching selenium a selenium grid node, and it's actually configured from a JSON object, and will actually send that object to the server. You can see the configuration here. It's registering that node on the grid and it's constantly hitting the grid hub in order to get the status to figure out if it needs to run any test.

So if you look at the console now in "http://localhost:4444/grid/console".

You can see that we've got one Remote Proxy here, and we can see what ip address is listening on. And you can see it supports up to 5 concurrent tests and if you hover over one of the small icons you can see what the configuration is.

In this case the protocol is Selenium, platform is Windows 8, browser name is Firefox and then the max instances is 5.

And you can see we can call Google Chrome on here, 5 instances running at the same time. We can have Internet Explorer with 1 instance. You can also notice we have Remote Control (legacy), this is the old selenium (Selenium 1). So it allows you connect using Web Driver or through the old style selenium RC.

So that's our first node. Now we need to setup our second node.

Setting up the second node (PC2 - Ubunto Linux Virtual Machine)

In this second node, we'll be running a instance of Ubunto (Linux) operating system. To do that, we'll be using Virtual Box. The purpose of this post it's to guide how to setup a distributed testing environment using selenium grid. So we'll skip Ubunto setup and configuration of the virtual machine.

Once the virtual machine is setup with Ubunto and JRE, we go ahead and run a new node on it by running the same exactly process we did for creating the first node. By typing in a terminal windows "java -jar selenium-server-standalone-2.41.0.jar -role node -hub http://172.16.0.45:4444/grid/server".

Notice that the ip address changed because we are not using localhost anymore. Instead we are pointing our new node to the first machine (PC1) which is ip address is 172.16.0.45.

After launching we can see the second node is running in grid mode, same as node 1 in PC1.

And now we can go ahead and refresh our console in PC1 and we can notice we have a second Remote Proxy here. You can see what the address of that proxy is, and then it's on port 5555 running Linux OS.

Now, one thing to notice here also is that you need to make sure that your firewall settings are allowing selenium server to connect through the port here. 

So, for example, our hub (PC1) is on port 4444, on the PC2 I had to make sure I had allowed firewall out on PC2 and then in on the machine PC1 allowing connections coming from port 4444.

And if you don't do this, then you'll see it won't connect.

So next, I'm gonna set up an additional node on my Mac.

Setting up the third node (Mac - OS X 10.9.2 Mavericks)

After running the third node on my Mac, and I did exactly the same thing I did on PC2.

I just ran "java -jar selenium-server-standalone-2.41.0.jar -role node -hub http://172.16.0.45:4444/grid/server".

So let's go ahead and refresh this console again in PC1, and now you can see there's a third node there.

So now we are able to run remote test on a Mac as well.

We have just setup a basic configuration.

Next we'll see how to run some tests, just to verify their configuration works.

If you want to do a more advanced configuration, you can go to http://code.google.com/p/selenium/wiki/Grid2

This is basically the Google code page for selenium and inside the wiki there on grid, you can find here some more information. And you can find all the information we have covered, about how to start up selenium server as a node. But also what you'll find here, how to configure nodes by command lines and they give some instructions here how to do that. It tells you what the optional parameters are. And the basic things you might wanna change here are the things like the maxSession parameter, so how many tests can be running simultaneously and the browser type in parameters to maybe test different versions of a browser. You have actually the ability to chose the version number of the browser where you want to test. You just have to specify where that browser is. If you use one other than the current version.

-browser browserName=firefox,version=3.6,firefox_binary=/home/myhomedir/firefox36/firefox,maxInstances=3,platform=LINUX

Another thing you can see how to do here, is to configure your nodes by JSON. And you can do that on the node and hub. You can have some samples of configurations that might be useful.

It's a pretty good way to do the configuration.

So now let's run our first test in our grid to make sure everything is working.

Actually we don't need to make any changes in our test class, since the hub where the nodes are connected are in my local machine. 

var driver = new RemoteWebDriver(new Uri("http://localhost:4444/wd/hub"), DesiredCapabilities.Firefox());

Remember you can you different browsers, but you do have to set them up and configure them in which one of the nodes. So you'll have to setup Chrome or IE or whatever you want to use in that hub configuration.

If we look at our grid, we can see we've got three nodes here, and even dough it shows all of this browsers they are not necessarily all available. 

For example, on my Mac, I don't have Internet Explorer. But this is just the default. Remember you can change that configuration if you want to, in order to specify what browsers, how many are allowed and where the drivers are located.

If we'll run the tests it as it is, it would pick up a node that can run our tests according to the Desired Capabilities we selected. In this case Firefox. It picked up my local machine PC1 for that.

That was successful, but now let's do something to make sure that we get the Mac version.

What we can do here, is to change the Desirable Capabilities. 

So instead of just doing DesiredCapabilities.Firefox() and replace it to new DesiredCapabilities("firefox", "", new Platform(PlatformType.Mac)).

We will not specify the version of Firefox we want leaving the second argument as a empty string. We'll have:

var driver = new RemoteWebDriver(new Uri("http://localhost:4444/wd/hub"), new DesiredCapabilities("firefox", "", new Platform(PlatformType.Mac)));

So we can run this and watch the Mac executing the tests using Firefox.

Final Considerations

I would like to cover a one more point about selenium grid mode. 

That point is Parallel Execution. We didn't look at doing Parallel Execution, and that's it because it's really not part of Selenium or the grid framework itself. 

It's a little bit confusing to sum when you're expecting that if you use grid, that your tests will just automatically be executed in parallel. And that's not necessarily the case.

You have to do something to make that happen. So, for example, let's say that we wanted to run 10 test cases at a time, and maybe you have a 1000 test cases or so. You would need to, in the way that you run your tests, set up parallel execution. In your test project, perhaps you would spin off threads running your tests and they will all hitting the same hub. And that hub can execute them in parallel. 

But doing that, we are actually controlling the parallelization of our tests at the level where we are running them or where the driver of the test is. 

But basically you are responsible for parallel executing. The grid makes it possible, but you have to initiate it.