Selenium, just that easy.

I recently needed to set up a workflow for testing the front end of a client’s web app.  We wanted to simulate various users and interact with the system as they would, so Selenium WebDriver was an obvious choice.  I was amazed at how easily I could get up and running without ever having used it before, so I thought a quick intro post would be fun.

For this tutorial I’ll be using the ChromeDriver utility.  You’ll need to ensure you have it to follow along.  Additionally, Selenium will need to find the utility.  It will default to using your PATH variable but in this case I will directly reference the path to the utility.

As a starting point, let’s load up Visual Studio and create a new Console Application.  From there, load up Package Manager Console and enter:

Install-Package Selenium.Support -Version 2.53.1

You can also use the GUI tool to search for Selenium.Support version 2.53.1 if you prefer.  Either way, this installs Selenium.WebDriver for controlling ChromeDriver and Selenium.Support for a set of useful extensions.

Now to get to the meat.  Rather than building yet another, “Hello World,” and using Selenium to verify its functionality, I thought would be fun to automate a common task.  I’ve been dreaming of getting a Subaru WRX for a while now, and I thought I’d run through checking listings on one of the sites I check occasionally.  Without further ado:

open OpenQA.Selenium.Chrome
open OpenQA.Selenium.Support.UI
open System
let pathToChromeDriverUtility = @"C:\WebDrivers\"
let myLocalZip = "29063"
let (|Int|_|) str =
match Int32.TryParse(str) with
| (true,int) -> Some(int)
| _ -> None
let isInt text =
match text with
| Int i -> true
| _ -> false
// If the path to the ChromeDriver executable is not
// part of the path variable, it's easiest to
// simply provide the constructor with the directory
// path.
let driver = new ChromeDriver(pathToChromeDriverUtility)
[<EntryPoint>]
let main argv =
// Load up the cargurus home page.
driver.Navigate().GoToUrl("https://www.cargurus.com&quot;)
// Grab the select element for the make.
let makeSelect = driver.FindElementById("carPickerUsed_makerSelect")
|> SelectElement
// Because I like them.
makeSelect.SelectByText("Subaru")
// Grab the select element for the model.
let modelSelect = driver.FindElementById("carPickerUsed_modelSelect")
|> SelectElement
// Because VROOM VROOM.
modelSelect.SelectByText("WRX")
// Grab the input for the Zip Code where I'll search.
let zipInput = driver.FindElementById("dealFinderZipUsedId")
// Enter my local zip.
zipInput.SendKeys(myLocalZip)
// Grab the search button.
let searchButton = driver.FindElementById("dealFinderForm_0")
// Click it FTW!
searchButton.Click()
(*
This is a quick one off, so we won't be parsing the entire result set.
For now, let's just see what the closest available options are.
We could easily extend this to be far more intelligent, but this
shows the basics well enough.
*)
// Grab the select element for sorting.
let sortBySelect = driver.FindElementById("dealFinder-sortHeader-select")
|> SelectElement
// Order the result set by proximity.
sortBySelect.SelectByText("Closest first")
// Get the distance spans for all listings.
let allDistances = driver.FindElementsByCssSelector("div#listingsDiv span.cg-dealFinder-result-stats-milesAway, div#featuredResultsDiv span.cg-dealFinder-result-stats-milesAway")
let distanceText = allDistances |> Seq.map (fun span -> span.Text.Replace("mi", "").Trim())
distanceText |> Seq.filter (isInt)
|> Seq.map (Convert.ToInt32)
|> Seq.sort
|> Seq.iter (printfn "%i miles away")
driver.Close()
Console.ReadLine() |> ignore
0 // return an integer exit code

If you prefer C#:

using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using OpenQA.Selenium.Support.UI;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace SeleniumCSharp
{
class Program
{
private static string pathToChromeDriverUtility = @"C:\WebDrivers\";
private static string myLocalZip = "29063";
private static bool IsInt(string s)
{
int ignore;
return Int32.TryParse(s, out ignore);
}
static void Main(string[] args)
{
// If the path to the ChromeDriver executable is not
// part of the path variable, it's easiest to
// simply provide the constructor with the directory
// path.
var driver = new ChromeDriver(pathToChromeDriverUtility);
// Load up the cargurus home page.
driver.Navigate().GoToUrl("https://www.cargurus.com&quot;);
// Grab the select element for the make.
var makeElement = driver.FindElementById("carPickerUsed_makerSelect");
var makeSelect = new SelectElement(makeElement);
// Because I like them.
makeSelect.SelectByText("Subaru");
// Grab the select element for the model.
var modelElement = driver.FindElementById("carPickerUsed_modelSelect");
var modelSelect = new SelectElement(modelElement);
// Because VROOM VROOM.
modelSelect.SelectByText("WRX");
// Grab the input for the Zip Code where I'll search.
var zipInput = driver.FindElementById("dealFinderZipUsedId");
// Enter my local zip.
zipInput.SendKeys(myLocalZip);
// Grab the search button.
var searchButton = driver.FindElementById("dealFinderForm_0");
// Click it FTW!
searchButton.Click();
/*
This is a quick one off, so we won't be parsing the entire result set.
For now, let's just see what the closest available options are.
We could easily extend this to be far more intelligent, but this
shows the basics well enough.
*/
// Grab the select element for sorting.
var sortByElement = driver.FindElementById("dealFinder-sortHeader-select");
var sortBySelect = new SelectElement(sortByElement);
// Order the result set by proximity.
sortBySelect.SelectByText("Closest first");
// Get the distance spans for all listings.
var allDistances = driver.FindElementsByCssSelector("div#listingsDiv span.cg-dealFinder-result-stats-milesAway, div#featuredResultsDiv span.cg-dealFinder-result-stats-milesAway");
var distanceText = allDistances.Select(span => span.Text.Replace("mi", "").Trim());
var orderedDistances = distanceText.Where(IsInt)
.OrderBy(text => Convert.ToInt32(text));
foreach (var dist in orderedDistances)
Console.WriteLine($"{dist} miles away");
driver.Close();
Console.ReadLine();
}
}
}

The sky’s the limit from here.  You can do much more complex and involved workflows and combining it with unit testing is a breeze.  Please, let me know if you’d like more posts on this subject.

Lastly, a disclaimer.  I’m not trying to advertise for cargurus, nor am I advocating scraping their or any site.  This is just meant to be a fun display of the power of Selenium WebDriver.  It can help you nail down your UI testing, or it could just start your favorite websites when you boot your PC.  Just remember, don’t be evil.

What’s so good about immutability?

When I first started learning functional programming, immutability was one of the great looming walls which I encountered.  I kept looking for some deep and complex reason that variables shouldn’t mutate, when in fact, the reason is very, very simple.  Immutable variables make code more predictable.

Let’s say you and I, and ten others are seated in a circle.  You need to pass a message to everyone, but you can’t do it by speaking.  “Aha,” you declare.  “I’ll write a note, and everyone can pass it down!”  If I asked you at this point whether you’d like the note laminated, what would your response be?

My guess is, you’d answer, “No, thanks.  It’s just going around the circle.”  Seems pretty reasonable, when you’re just making sure 11 people get the same message, especially if you know and trust them.  What if you needed to pass the note to a thousand people, or ten thousand?  The note might get ripped, smudged, or some troll might deliberately change it.

Laminating the message ensures that everyone gets the same message, and that is where immutability becomes powerful.  Know what the difference is between this:

var message = "This is a message.";
logger.Log(message);
var messageInQuotes = "\"" + message + "\"";

and this?

let message = "This is a message."
logger.Log message
let messageInQuotes = "\"" + message + "\""

The difference is that we can only predict the value of messageInQuotes in the second code example.  In the C# example, once the message variable is passed into the Log method, you are allowing it or any methods it calls to change the state of the message.  With immutable variables, you can predict the state of messageInQuotes.

This may not seem earth-shaking or profound, and that’s because it isn’t.  Like the best things in programming, it’s incredibly simple.  If you’re writing a ten-line console app, who cares about mutability?  When you’re working with ten-million lines of code, event-driven asynchronous processing, and multi-threading (or as I like to call it, enterprise development), you might want to care. 

Going back to our analogy of ten-thousand people all getting the same message, you don’t have to assume there’s a bad egg.  People make mistakes all the time.  Maybe the message was, “There’s a party on Fulton St,” and someone thought, “I don’t know a Fulton St.  You must have meant Fuller St.  I’ll fix it for you and pass it on.”  Only with software, it’s that one errant function.

I’m not trying to say that C# is bad, or that F# is better.  Both C# and F# offer mutability and immutability.  With any language, enterprise-scale development is complicated and complexity reduces predictability, which in turn reduces reliability.  Immutability can help your code to be more predictable, and (IMHO) more readable. 

In closing, look at the following code.  Assuming we want to get the reversed value of an original string, is it clearer to pass the string to a function which will reverse it, or to pass it into a method which will return the reversed value and then assign that value to a new variable?

// relying on mutability
public void ReverseString(string forwards)
{
var chars = forwards.ToCharArray();
Array.Reverse(chars);
forwards = new String(chars);
}
ReverseString(message);
// immutable implementation
public string ReverseString(string forwards)
{
var chars = forwards.ToCharArray();
var reversedChars = chars.Reverse().ToArray();
return new String(reversedChars);
}
reversedMessage = ReverseString(message);

F# Type Providers: 0 to Data in a Single Line of Code

More and more I’ve been working in F#.  Part of it is needing a REPL in an environment where I can’t use my normal tools.  Part of it is that working in a different paradigm changes how I code.  Overall, I love the language and learning it has been a blast!

Recently, however, I was listening to a great DNR with Rachel Reese and the subject of Type Providers was raised.  They have tradeoffs like anything else, but imagine a fully typed model in a single line of code.  Better yet, why don’t we make one?

Before we begin, I’m going to assume you have access to a SQL Server instance, a copy of Visual Studio, and F# installed.  If anyone reading this either doesn’t have access or would like help getting set up, please let me know in the comments and I’ll try to assist.

Let’s start with a database.  I’ll use Northwind for this example, but any will serve.  Next, we need an F# class library project.  Let’s call it TypeProviders.

A picture of the new project dialog in VS 2015.  We're using an F# library project and calling our project TypeProviders.

You should start out in a new F# file, with the following:

namespace TypeProviders

type Class1() =
     member this.X = "F#"

Now we need to reference a few assemblies.  For now, let’s go with System.Data.Linq, and FSharp.Data.TypeProviders.

An image indicating the two references; System.Data.Linq, and FSharp.Data.TypeProviders.

 

Now I have a terrible confession.  I lied.  If we count open/using/import statements, it’s actually a whopping four lines of code:

namespace TypeProviders
 
open System.Data.Linq
open Microsoft.FSharp.Data.TypeProviders
open System.Linq
 
type public NorthwindContext = SqlDataConnection<"Connection-String-Here">

That’s it.  You’re done.  You now have a strongly typed model of the entire database!  Don’t believe me?  That’s fair.  Let’s explore.  Let’s open System.Linq and:

namespace TypeProviders
 
open System.Data.Linq
open Microsoft.FSharp.Data.TypeProviders
open System.Linq
 
type public NorthwindContext = SqlDataConnection<"Connection-String-Here">
 
module WorkingWithProvider =

     // Alias the type so we don't have to reference 
     // the full path to the type.
     type Shipper = NorthwindContext.ServiceTypes.Shippers

     // A function which determines whether the 
     // passed Shipper is named "Speedy Express"
     let nameIsSpeedy (company: Shipper) =
          company.CompanyName = "Speedy Express"

     // Grab SpeedyExpress from the database
     let speedy = NorthwindContext
                     .GetDataContext()
                     .Shippers
                     .Where(nameIsSpeedy)
                     .Single()

That’s it.  We already can grab a particular entity from a particular table and we didn’t need to define a single one of the types.  Where you see the type Shipper declared, we’re just aliasing it for readability. 

“Ok.  Not bad.  What else?” 

How about having your stored procedures automatically wired up for you?

// Maps directly to the Stored Proc
let getSalesByYear = NorthwindContext
                         .GetDataContext()
                         .SalesByYear

“Ok.  That’s pretty cool.  Problem is, I’m a C# developer.  I can’t use this.” 

Why not?  It’s all IL, right?  Let’s create a C# project called ConsumeTypeProvider:

A picture of the NewProject window, with a CSharp console project selected, and the name ConsumeTypeProvider.

Then we’ll reference our TypeProvider project and System.Data.Linq:

An image showing that the new C Sharp project ConsumeTypeProviders, references the F Sharp project TypeProviders, and System.Data.Linq.

Voila:

static void Main(string[] args)
{
     var db = TypeProviders
                 .NorthwindContext
                 .GetDataContext()

     var speedy = db.Shippers
                    .Where
                    (x => x.CompanyName == "Speedy Express")
                    .Single();
}

“Ok.  I can use it.  Should I?” 

Great question!  It depends.  Unless you alias the types, you’ll need to reference every type as [TypeProviderName].ServiceTypes.[ActualTypeName].  It’s a bit much.

Also, these aren’t EF Power Tools generated partial classes.  Speaking of a bit much.  If you want your model to have more functionality than the provided types, you’ll need to subclass them or write adapters, which cuts into the time savings.

“Any gotchas?” 

Well, the data-context entities expose the System.Data.Linq.ITable interface.  As an EF guy, I’m not a huge fan of the different API.  Check back later and I’ll show you the more EF friendly Sql Type Provider.

Also, the Type Provider is, by default, dynamic.  Every time you compile, it checks the database.  That means compiling will be slower, but not enough that I mind. 

You can set the Type Provider to a static schema, but I would advise against it.  When dynamically generated each build, your Type Provider is a perfect reflection of your database.  If the Type Provider changes its types such that it breaks your application, it means your database has been changed such that it breaks your application.  Dynamic type generation can warn you if your database has breaking changes.

“Anything else?”

Yes, sorry.  One last thing.  There’s a lot more to Type Providers, and just this particular one, than I can show you in a single post.  When you have time, there’s more information on MSDN.