Interacting with Microsoft Excel from C# using EPPlus – Part 1

I’ve been working on moving the reporting functionality of an existing application from HTML to Microsoft Excel format. I find HTML fine for creating simple reports or sometimes log files from C# applications, but these reports were churning out at around 50MB, which Internet Explorer was having serious problems dealing with. So, I decided to solve this issue by moving all reporting functionality in the application to Microsoft Excel format, which with hindsight I would have done in the original design.

EPPlus is an open source .NET library for reading an writing Excel files. I’ve used this in many projects, and have found it invaluable when the requirement to either read or write Excel files crops up. In this post, I’ll give examples of using EPPlus to write to a Microsoft Excel file.

Setup

Create a new C# console application project in Visual Studio. Download the EPPlus binaries from the Downloads section on the EPPlus CodePlex Site.

Extract the files and add EPPlus.dll as a reference to your project.

Writing to Excel

EPPlus writes Excel 2007/2010 files using the Open Office Xml format (xlsx). The first thing to do, after the initial setup has been completed, is to add the following imports to your code:

using OfficeOpenXml;
using OfficeOpenXml.Style;

Next, let’s create a new ExcelPackage and add some properties to it such as the author, title and company:

using (ExcelPackage p = new ExcelPackage())
{
    p.Workbook.Properties.Author = "Miles Dyson";
    p.Workbook.Properties.Title = "SkyNet Monthly Report";
    p.Workbook.Properties.Company = "Cyberdyne Systems";
    
    // The rest of our code will go here...

}

Now we’ll need to create a new worksheet where we will add our data:

    p.Workbook.Worksheets.Add("April 2012");
    ExcelWorksheet ws = p.Workbook.Worksheets[1]; // 1 is the position of the worksheet
    ws.Name = "April 2012";

We’ll be adding some simple data to this worksheet, contained in 3 columns. We might want to add a header to this worksheet with some column names, and some basic formatting, like making the column header background color something different.

This is simple to achieve using EPPlus:

    int rowIndex = 1;
    int colIndex = 1;

    do
    {
        // Set the background colours
        var cell = ws.Cells[rowIndex, colIndex];
        var fill = cell.Style.Fill;
        fill.PatternType = ExcelFillStyle.Solid;
        fill.BackgroundColor.SetColor(Color.LightGray);
        colIndex++;
    }
    while (colIndex != 4);

    // Set the cell values
    var cell_actionName = ws.Cells[1, 1];
    var cell_timeTaken = ws.Cells[1, 2];
    var cell_processorsUsed = ws.Cells[1, 3];

    cell_actionName.Value = "Action Name";
    cell_timeTaken.Value = "Time Taken";
    cell_processorUsed.Value = "Processing Unit";

The above two actions will be quite common if you use EPPlus to write to Excel files in a lot of different projects. I’d recommend created a static helper class to perform both of these functions (adding the properties and creating a header), I’ve done this with these and other common functions, and I’ve found it’s saved me some time.

Note that we haven’t actually saved the Excel file yet, it’s in memory but we haven’t saved it to disk. Before we do, let’s add some data to it as well as the header. For the purpose of this example, let’s say we already have the data (wherever it may have come from), defined as a List of hypothetical ProcessorAction Objects.

In order to write the data to the file, we can just iterate over this List and write a new row for each ProcessorAction Object to the Excel file:

    // Get hypothetical data...
    List processorActions = DataAccessHelper.GetProcessorData(DataTime.Now);
    
    // Column indexes for clarity
    int actionColIndex = 1;
    int timeColIndex = 2;
    int processorColIndex = 3;

    int rowIndex = 2; // Row 1 is the header

    foreach(ProcessorAction p in processorActions)
    {
        // Action
        var actionCell = ws.Cells[rowIndex, actionColIndex];
        actionCell.Value = p.Action;        

        // Time
        var timeCell = ws.Cells[rowIndex, timeColIndex];
        timeCell.Value = p.Time;
        
        // Processor
        var processorCell = ws.Cells[rowIndex, processorColIndex];
        processorCell.Value = p.Processor;

        rowIndex++;
    }

Now that all our data is written, we want to save the Excel file for distribution:

    // Save the Excel file
     Byte[] bin = p.GetAsByteArray();
     File.WriteAllBytes(@"C:\Reports\Report.xlsx, bin);

Your file should save successfully. That’s the basics of writing to Excel files using EPPlus. In the next post, I’ll outline how to read data contained in an Excel file into memory.

Happy Coding 😉

Interacting with web pages using Selenium WebDriver for C#

I’ve been using Selenium WebDriver for C# a lot lately, for a number of projects that involved interacting with a web browser in some manner. I’ve used a lot of applications and libraries over the past few years that provide this functionality, but I’ve never come across one as intuitive and reliable as Selenium WebDriver – if you work on any projects that involve interacting with a web browser to automate some process, you need to read this post.

In this post I’ll take you through the process of using Selenium WebDriver to automate some interaction with a web browser and hopefully show you how powerful Selenium is. We’ll take a simple scenario as an example – submitting a request to the Google search engine.

Boot up Visual Studio and create a new C# console application. You’ll need to download the Selenim WebDriver for C# ZIP from Google Code, and add the DLL’s it contains as references to your project. For this example, you are only required to add WebDriver.dll and Newtonsoft.Json.Net35.dll. You’ll need to add the following using statements also:

using OpenQA.Selenium;
using OpenQA.Selenium.IE;

Now your ready to write some code that can drive your web browser. First, we’ll need to create the object that can do just that. With Selenium WebDriver, that is an IWebDriver object. This object can be instantiated to control Internet Explorer, Firefox, or Chrome. In this example, I’m going to use Internet Explorer.

IWebDriver driver = new InternetExplorerDriver();

You could also use ChromeDriver or FirefoxDriver above.

Next, let’s navigate to the Google website. The following code will handle this. One of the nice things about Selenium is that this call won’t return until the page is loaded in the browser. Other frameworks and libraries return immediately, requiring you to add waits/sleeps in your code to ensure the page is actually loaded, which is a terrible approach.

driver.Navigate().GoToUrl("http://www.google.com");

Aside – Internet Explorer Problems

One setting has to be changed in Internet Explorer in order for Selenium WebDriver to work correctly. Your security zones need to have protected mode either enabled or disabled – it doesn’t matter which, as long as it’s the same for each zone. I’ve got it set to on for each zone on my machine. To achieve this follow these steps:

  1. Open IE and go to Internet Options.
  2. Go to the ‘Security’ tab.
  3. Click on each of the zones, i.e. ‘Internet’, ‘Local intranet’, ‘Trusted sites’ and ‘Restricted sites’ and ensure that the ‘Enable Protected Mode (requires restarting Internet Explorer)’ check box is checked.

At this point, build your project in Visual Studio and run it. If you have followed the above steps correctly you will see Internet Explorer open, and navigate to Google automatically.

Now to actually interact with the open web page, Google in this case. In order to submit a search term, we’ll need to interact with the search term text box (to enter a search term), and the ‘Google Search’ button (to submit the request).

To do this, we’ll need to look at the source code for the page, to find the information we’ll need to interact with these controls. From looking at the source code, we can see that the markup for these controls looks like the following (formatted and commented for clarity):

Google Search

So, lets define the search term text box, and enter a search search:

IWebElement searchTermTB = driver.FindElement(By.Name("q"));
searchTermTB.SendKeys("jimmy collins blog");

Take note of what we’re doing here – we’re using the browser object we defined earlier to find an element with the name ‘q’. This is another great thing about Selenium – we can use just about any element attribute to try to find it, you could also use the ID, class name, tag name, or even the XPATH to find an element on the page.

Now build and run your application – you will once again see Internet Explorer opening up, but this time you’ll also see the search term being entered.

The final step is to actually click the ‘Google Search’ button and submit the query. The same approach that we used to find and interact the search term text box is followed:

IWebElement searchBtn = driver.FindElement(By.Name("btnG"));
searchBtn.Click();

Running your application now will open up Google, enter your search term, and hit the search button. The final thing to do is some cleanup – you will notice that currently when your application runs, the browser is left open once it completes. All we have to do to close the browser is:

driver.Close();

That’s how easy Selenium is to use. The ideal scenario is that you have interaction with your development team, and get them to agree to providing static IDs on all controls, that don’t change between versions of your site (unless in the case of a substantial UI revamp). That would make it a simple task to provide re-usable automation that can automatically verify changes to your site, or be used for regression testing.

Some Useful Android Debug Bridge Commands

As I mentioned in a previous post, the Android Debug Bridge is a hugely useful command line tool which installs with the Android SDK, to the ‘platform-tools’ directory.

If your doing any development or testing on Android devices, this is a must to have installed on your machine. I recommend adding it to your Windows PATH variable, as once you begin to use it, you’ll find yourself coming back to it more and more.

In this post, I’ll outline some of the most useful commands I’ve been using in my interactions with Android so far. First off, ensure you have an Android device connected to your machine, or an emulator running.

adb provides a command for determining what Android devices are detected to your machine, ‘adb devices‘:

adb devices command

Use the above command to ensure that adb detects your device or emulator. For example, it may not detect a physical device if you don’t have the correct USB drivers installed.

Here are some of the other commands that should prove useful to you when working with Android devices. Note that for some of these commands to work, you will need to a rooted Android device.

Install an APK file

adb install path_to_apk_file

Uninstall an APK file

adb uninstall com.myapp.main

View the device log buffers

adb logcat

Switch locale on the device (to German in this example)

adb shell “su -c ‘setprop persist.sys.language de; setprop persist.sys.country de; stop; sleep 5; start’

Start intent e.g. your applications main Activity

adb shell am start -a android.intent.action.MAIN -n com.myapp.main/.activities.MainActivity

Run all Instrumentation tests in a Java class against an application

adb shell instrument -e class com.myapp.tests.UITests -w com.myapp.test/android.test.InstrumentationTestRunner

Get a dump of the devices configuration (useful to include in bug reports)

adb bugreport

These are the commands I’ve found most useful when working with Android so far, view all available commands by typing adb -h from the command line.

Happy New Year.

Java Needs Automatic Properties

One of my main grievances with the Java programming language is it’s lack of Automatic Properties. These have existed in C# since .NET 3.0.

Automatic Properties make property-declaration more concise when no additional logic is required in the property accessors. For example, let’s say we want to implement a simple Book abstraction in an application, with four simple properties for arguments sake.

This is how it may look in C#:

public class Book
{
    public string Name { get; set; }

    public string Author { get; set; }

    public string ISBN { get; set; }

    public string Genre { get; set; }
}

Nice and simple, and written in about 1 minute when coupled with Visual Studio’s intellisense etc.

Now, lets take a look at a class offering the same basic functionality in Java:

public class Book 
{
    public String Name;
    public String Author;
    public String ISBN;
    public String Genre;
    
    public void setName(String name)
    {
        Name = name;
    }
    
    public String getName()
    {
        return Name;
    }
    
    public void setAuthor(String author)
    {
        Author = author;
    }
    
    public String getAuthor()
    {
        return Author;
    }
    
    public void setISBN(String isbn)
    {
        ISBN = isbn;
    }
    
    public String getISBN()
    {
        return ISBN;
    }
    
    public void setGenre(String genre)
    {
        Genre = genre;
    }
    
    public String getGenre()
    {
        return Genre;
    }
}

Just on a lines of code basis, it’s easy to see that C# wins overall. I understand that the designers of Java may not want to add this functionality to the language due to potentially breaking millions of current Java applications – but I’m sure it could be added in such a way that new applications could use it without breaking legacy applications.

Hell, a third party library, Project Lombok, already provides support for using Automatic Properties in Java, so it’s definitely possible.

I find this limitation really frustrating when working with Java.

Back To Java & Some Android Test Automation

I’ve been getting back into some Java programming lately, and for the most part, have enjoyed it immensely. I say ‘for the most part’, because I initially had the misfortune to install the Eclipse IDE. What an absolutely horrible application. OK, it’s great that it’s a free development environment, and for the most part works as expected, but it’s not the most intuitive application to use. One of my main annoyances also was the large amount of Eclipse related project files created for simple projects.

For example, for a simple application created in Eclipse, my ‘.metadata’ folder contain 546 files! I honestly have no idea what 95% of these files were for, and they changed. They changed a lot. For reasons I have no idea of. This really annoyed me as I use SVN as my source control system, and had permanently red folders – I’ve got a touch of OCD when it comes to knowing exactly what files I’ve changed and for what reason. Eclipse lasted three days on my system (two of those were the weekend).

Enter NetBeans 7.0.1. Having last used NetBeans around version 4 (around 2007 I think), I was expecting radical changes. There are some major changes, but to my surprise, all for the better. The simplicity of the IDE has been retained – everything was either where I remembered it, or where I expected it to be – a far superior machine to the aforementioned Eclipse.

My main reason for interacting with Java again, is related to one of my current work projects. I don’t have to say that the mobile applications arena has exploded in the last few years – that statement is quickly becoming a cliché. One of the areas which needs to receive significant attention in my opinion is the area of mobile test automation. Some great tools already exist, but many are in their infancy. The problem also grows when you think of the requirement for any mobile test automation system to work across multiple versions of Android, and also multiple languages.

Doing some research on Friday afternoon, I came across MonkeyRunner. This is an Android supported API that provides the ability to interact with and control Android devices (physical or an emulator).

Deciding to take a look, my first hurdle was setting up my NetBeans IDE to work with the Android SDK. The Android developers documentation is heavily biased towards Eclipse, why I’m not sure. Having been sure someone had faced this challenge before, I turned to Google, and sure enough Binary Wasteland had an excellent article on setting up the Android SDK in NetBeans.

Next question – which test automation requirement to try to implement? The answer – the ability to take screen captures of applications running on an Android device. Our localization department use screen captures heavily, for unit testing of localized UI’s, screen shots for documentation, marketing requests etc. So such a feature would have to be included in any mobile test automation system.

To digress for a moment, I have to mention ADB. The Android Debug Bridge is an excellent command line tool that installs with the Android SDK. It allows you to connect to your Android device (wired or over WiFi), and install applications, remove applications, get certain properties of the device (e.g. the language), dump the entire configuration from the device for use in bug reports, along with many other features. Take a look in the ‘platform-tools’ directory in your Android SDK folder, adb.exe will be located in here. I suggest adding this directory to your Windows PATH variable, as you will find yourself using it a lot.

But back to the feature for taking screen captures of an Android device. This is quite simple. Some examples I found on the internet seem to be out of date since Android 4.0 (Ice Cream Sandwich) was released. There seems to be a new package called ‘ChimpChat’, which contains a wrapper for the ADB, and also the functionality for taking a screen capture previously contained in the MonkeyRunner package.

Time for some code:


import com.android.chimpchat.core.*;
import com.android.chimpchat.adb.*;

public static void main(String[] args) 
{ 
        AdbBackend adb = new AdbBackend();
        IChimpDevice device = adb.waitForConnection();
        
        IChimpImage image =  device.takeSnapshot();
        image.writeToFile("C:\\Test.png", "png");
        
        device.dispose();
}

The above code will do the following:

  • Create a new instance of the ADB wrapper.
  • Create an IChimpDevice, and wait for a connection.
  • Take a screenshot, and save it to the location specified.
  • Close the connection to the device.

I have some questions though. ADB seems to only support one connected device, and always connects to the first one it finds if more than one device is connected. What if I want to interact with a number of Android devices, e.g. a mobile phone and a tablet? I need to look into this.

I also need to figure out how we will interact with our complex mobile application UI’s, how specific UI elements will be identified, and if we can programmatically switch the language settings on attached Android devices.

But the above is a good start towards a re-usable mobile test automation system.

Google Search Results Weirdness

Over on Twitter, @semperos has brought an interesting point to my attention. My posts from this blog, when indexed by Google, have the date ‘August 29th 1997’ in the meta data relating to the result. This gives the impression that posts were written on this date:

Google Search Results

It seems that GoogleBot is taking the date from the text in the banner on my site:

My website banner

(From one of my favourite movies)

This is contrary to everything I’ve read, which states that Google’s crawler is either smart enough to recognise the date of your last post, or this is the date of the last crawl. The above screen captures obviously rule out both of these possibilities.

It looks, to the Google outsider like myself, that GoogleBot is just taking the first date it finds on a page it is crawling, and using that in the description on the search results page.

If anyone from Google happens to read this – I’d love an explanation or clarification…