Archive | Development RSS for this section

Programming C# 5.0 By Ian Griffiths

Programming C# Cover

I read Learning C# in the spring of 2012 and it effectively introduced me to the language of C#. Programming C# 5.0 is a more technical introduction to the language, showcasing not only deeper technical explanations of language features but also some explanation of preferred approaches to using these features.

The acceleration through the topics felt good, with the first ten chapters reviewing what I would consider essential features of C# (my favourites being the chapters on LINQ and delegates) and the next nine chapters reviewing more advanced features such as asynchronous features and reflection. The remaining two chapters, ASP.NET and interoperability, felt awkward but essential.

What I appreciate most about this book is the perspective it gives you for C# and as part of the .NET Framework. Whereas the tools I use when writing an application in C# make recommendations or show connections to relevant options, this book describe the technical underpinnings of the code. It helped in understanding where to use the features instead of how. Some of the topics weren’t applicable to the kinds of applications I’m writing now, such as the chapters on Reactive Extensions or multithreading, but I can easily go back to read about these features or to reintroduce myself to more complex areas. The book also does a really decent job of cross-referencing material, directing the reader to different sections of chapters that are also relevant.

I would recommend this book to programmers who have become familiar with C# but want to grow, for experienced programmers who want more than an introduction to the language or for those who are familiar with C# but want to understand more about how the language is implemented in the .NET Framework.

Programming C# 5.0 is available on the O’Reilly site at


On Testing

What follows is my personal journey as a tester over the past year. Some of the success, hurt and frustration I’ve had is presented in a hopefully constructive manner. The wording on this is less conversational, yet I’m hoping with those who read it it does start a conversation in some way and also reminds testers that we have value and an obligation to those who want to learn about testing.

I always feel fortunate to be a part of companies who are producing software and I couldn’t imagine doing anything else. I am working with interesting, intelligent people and tackling problems that solve problems for other people. We are solving these problems using computers and code that create solutions that weren’t available to the majority of people twenty years ago. When I reflect on it, I’m amazed at the opportunities I am being offered.

The changes in the industry have been gigantic within the past few years, you can see them like tidal leviathans on the horizon. The learning and technical tools I have had access to are a result of those movements: Applications available from GitHub, public infrastructure from Amazon Web Services, a library of knowledge from experts and knowledge repositories easily accessible through Google searches. Last year I read twenty-two books for my career, ranging from test automation to Continuous Integration to C# and I have many more waiting to be read. The vast access to jumpstart skills sparks a fire I want to tend to and steadily grow until I can light fires for others and start them on their journey into the uncertainty of solving complex technical problems.

What does this have to do with testing software? The above prose could be for almost anyone who releases software. This is the point, the basis of what I want for testers. I want them to be equals alongside the artists and engineers, dancing around the fire with their teammates, sharing in the same danger and excitement.

People who work with testers want it too. As we shift to more frequent and adaptive releases and our projects involve more disciplines, testing raises in its importance. The activity of testing is not valuable, otherwise we would take more time for more elaborate and time-consuming tests. It is because of our skill and the value of what testers do when they apply them. For contrast, if the code developers wrote was the most valuable thing they could do, they would focus on producing more lines of code. Testing skills are discrete and valuable to a team, and it’s a full-on weeping shame that testers don’t appreciate or exercise them enough. Do you see the look of wonder on Aragorn’s face as he accepts Andúril and ultimately his responsibilities in the oncoming conflict? We should value ourselves and our role as much. Testers do not assure quality, yet we can apply tools like empirical thinking experiments, exploratory testing and general system thinking to help determine the solution’s qualities and readiness as part of a greater whole. Who doesn’t want mindful articulate thinking applied to their work as software development leans more towards business opportunities and less towards technical requirements? There is great concern and risk in releasing software on the Internet for a company. Companies want to invest money to have a more successful acceptance from those paying for it and those using it.

Aragorn holding Anduril
Aragon accepting Andúril  is a metaphor of what our acceptance
of our responsibilities 
as testers to our teams should be.

Developers who refuse to test are becoming scarcer as testing becomes a whole-team activity and the same is true for testers who refuse to code. Testing and coding are not exclusive skills and they can be learned and applied by the same person. Two applications of testing I have started to learn within the past year, unit tests and integration tests, still employ many of what I think of as the valuable thinking skills I’ve already mentioned. When we treat testing as a specialization instead of our role we can disrupt the pattern of segregation and share our testing skills to create a healthier team.

The companies, the methods, the tools, even the positions we’re hired for are always changing and until that itself changes, refusal to change and work as part of a team and adapt to the changes interferes with the quality of the software and the value it provides to its customers.

Edit: Replaced some words for general correctness.

Writing a UI automation framework with C#, part one

I spent some time earlier this year digging into UI automation, specifically an implementation a peer had started using C#, Selenium WebDriver and NUnit. At the time there was an ask for us to implement a sanity-level test of our team’s product and it seemed like the right time to become more familiar with the concepts around working with WebDriver.

What I found in the existing framework was an abstraction layer for WebDriver, and other objects to provide functionality for making testing more presentable to testers that had some familiarity with object-oriented concepts. There was also logic in the test fixture setup and teardown (a concept introduced from the NUnit test framework) to handle loading language-specific variables. These were all good features making a tool we could use in a variety of ways, and they aligned with what I was reading online, and we’re still using them today to develop our tests.

When I started focusing more on the UI automation we were doing, I started writing my own UI automation framework. My approach was to make something comparable based on what I was learning about C# and WebDriver, without using any reference material. Within a couple days I had something running, and in another day I had something that ran on Windows and Linux.

This is evidently a long preamble so that when I start explaining my design I don’t sound self-aggrandizing. There is also nothing particularly special in this article that can’t be found online and written by people that are much more into this than I am.


The UI automation framework I wrote contains a WebDriver abstraction, an element locator, explicit wait conditions and objects to support the page object design pattern.

WebDriver Abstraction

In order to provide more friendly methods to some of the obscured WebDriver functions I wanted access to, I created an abstraction object that translates something I want to do into the appropriate WebDriver call. For example:

public void SetImplicitWait(int seconds)

Aside from presenting a subset of more direct and specific user interactions with the WebDriver, this object also represents actions the user wants to do. So there are methods for clicking an element or entering text into an element on the page. (It’s worth mentioning that the elements are actually located in the DOM, but that the end result is a page being rendered in a browser, so I use page because it’s more evident.)

The WebDriver interfaces are still accessible through this object as well, so it’s possible to make calls directly if it doesn’t make sense to work through this abstraction layer. One example of this from my experiences so far, are for selecting a group of elements instead of one specific element using a FindElements method call.

Element Locator

Specifying elements on the page is a common action when working with UI automation using the WebDriver. So that a single object with readable methods would provide a way of returning a By object (used for working with other WebDriver methods, like the very important FindElement) I created a static object that did this. Here is an example of a call:

public static By ElementByValue(string value)
return By.XPath(String.Format("//*[text()='{0}']", value));

Others are more direct, taking a name of an element and doing a more direct lookup, for example.

Explicit Waits

WebDriver has the concept of implicit and explicit waits. In C#, it has a specific way of providing a wait condition through a lambda statement. I’ve found there are some common situations where you want to be able to wait, and that some of these are when you’re interacting with the WebDriver, but that this is also relevant when working with pages or tests. I made this functionality visible to any object wanting access to it.

An example of providing a wait for an element to become visible looks like:

public static void UntilElementIsVisible(Driver driver, By locator, int timeout)
WebDriverWait wait = new WebDriverWait(driver.webdriver, TimeSpan.FromSeconds(timeout));
wait.Until((d) => { return d.FindElement(locator).Displayed; });

Page Object Pattern Objects

From the different patterns I’ve seen, and from the different ways I’ve written Selenium scripts, for comprehensive functional automated UI testing, I like the page object pattern. Although I’m not as strict about how it’s generated or used, I found it useful to provide a base object with a few methods for what I would expect someone writing a test to want from a page they were specifying. These methods are for determining if an element is visible to a user or if an element has a specific value. An example of this would be:

public bool ElementHasValue(By locator, string value)
IWebElement element = driver.webdriver.FindElement(locator);
return (element.Text == value);

This also highlights another point in my overall design, to leave user actions to the Driver object and page validation actions to the base Page object.

In Closing

In writing this I hope it helps others who were at the spot I was at earlier this year, putting together the pieces of UI automation, in getting started on their journey.

For those interested, I’ve made this framework available on GitHub. I called it Kitsune, because right now it works with Firefox and I’m a fan of Japanese folklore and games which promote that rich cultural tradition. It has no relation to the Mozilla Foundation’s Kitsune project and they do two very different things.

How Google Tests Software by James A. Whittaker, Jason Arbon and Jeff Carollo


When I was on vacation towards the end of last year, I wanted to read a book that would help me along the path to become a better software tester. With that in mind, I chose How Google Tests Software and learned how a giant search company keeps software testing in-line with development practices.

For content, the book is divided into five sections: Introduction to Google Software Testing, The Software Engineer in Test, The Test Engineer, The Test Manager and Improving How Google Tests Software. This book serves two audiences: Those looking to learn from the test processes that define how Google tests its software, and to Nooglers (new Google employees) who need a launch point for learning about testing activities. Although the first four chapters serve both groups, the last section is more angled at the Nooglers. There are appendices at the back that show sample documentation for the described test processes.

This book approaches the major themes and concepts of testing activities at Google, and occasionally dips into more detailed information, such as tools that were developed or specifics of a task, like a brief glimpse into repo branching or the workflow of a Software Engineer in Test. What I learned from it is

  • The value of manual testers to solve specific problems
  • How prevalent coding is in all testing roles
  • Where automated tests can validate different parts of a system
  • Where a tester can develop tools and frameworks that help developers in their testing activities
  • How no one has it right and we all struggle with different problems

I’d recommend that testers read this book to get a look at how another company tests software. I learned things from it that I want to incorporate in my work and chances are others will too.

Switching to Ubuntu Pseudo-Finale

A month ago I posted about switching over to Ubuntu Linux, to compare it to Windows 7.  At the time I wasn’t sure what I would get out of it, because I had used Ubuntu as a primary OS at a previous job.

From my experiment, I found a few things:  Most importantly Ubuntu has improved.  When I had consistently used it last, audio was undergoing changes (I’m guessing the 10.04 release but I’m not certain), Gnome was the primary desktop manager, and virtualization support was good but mostly on the onus of the virtualization vendor.  This time around things were smoother and spending considerable time with Unity helped me to understand its benefits.

I also found that there were parallels to the applications I use.  It made me realized how fortunate I am to work in a field where there are many options for solving a problem, and at least some of them will be cross-platform and open source.  The point that really drove this home was the Microsoft .NET stack.  Not only is an implementation of it available on Linux as Mono, but many of their big projects are on Github.

It helped me to focus on the problem.  It can be easy to fall into the trap of learning about a language or pattern, but really what matters is identifying the problem and solving it.  I’m going to try and gear myself to do more of that.  This means I can set up a server with Bind, another with Apache with mod_mono, and still feel good about using Visual Studio Express on my laptop.  I want to see people getting past sticking with what they’re invested in and pick the right tool for the situation.

Version Control with Git by Jon Loeliger and Matthew McCullough

Version Control with Git book cover

Version Control with Git is a collection of experiences and wisdom about using Git in a variety of situations.  It reads as somewhere between technical manual pages and friendly parlance, which I think for many developers will be what they need.  Because Git is open source and there is an active community around using it this book won’t be the resource everyone will turn to, but it does have its place among those resources and I’ll be referring back to it in the future.

It starts off with the shared knowledge you need to understand Git and what how it works.  It doesn’t compare itself to other Version Control Systems and doesn’t get into apologetics about any systematic behaviour, it simply states what it does.  It walks through how it handles the working directory, the local repository and common commands like commit, log and diff.  What I think of as the introductory chapters end with a walkthrough of branching and merging, and their applications to the local repository.

At this point the book begins to get more technical, delving into more complex and theoretical areas like rebasing (altering the repository to a known point), remote repositories (a significant part of what makes Git a distributed VCS) and the reflog (what tracks the different endpoints, such as branches, of the repository).  These were harder for me to grasp, and although I appreciated that they were better than reading man pages or searching for discussions around these topics, often times I felt the authors neglected dicussing practical application of these concepts for providing more information about these concepts.  Given the constraints of the size of the book, I think they made the right choice.  Now that I’m aware of these topics, I’ll be going back as I get into using Git more and have to overcome some of its inherent limitations using the methods described.

If you are someone who wants to know more about the tools you use, or enjoy learning a system like how a VCS works such as I do, this is a book worth picking up.  The expertise of the authors and the depth to which they go into a variety of topics, should satisfy a reader’s curiosity about this interesting tool.

As a disclaimer, I received this book as part of O’Reilly’s Blogger Review Program.

Switching to Ubuntu Week 1

My first week of running Ubuntu 12.04 at home is done, and I’m on to week two tomorrow.  My objective for this week was to get into using Ubuntu and find equivalents to the applications I’m using on Windows 7.

I started last Monday with migrating some documents and pictures from 2012 to the VMware virtual machine I had started.  I also finished installing applications and setting up the typical web sites I use frequently.  I found that there were some compromises, like a lack of native applications for Evernote or Kindle, but that there is a good Evernote web application and a Kindle Chrome application.

Later in the week I set up a donated remote on another Ubuntu computer I have hooked up to our TV and unplugged the keyboard that we had been using.  I also had the opportunity late last week to stream a movie to my Raspberry Pi using NFS and omxplayer, and then had a geek-out moment and tweeted about it.  Looking into RaspBMC just became a near-future project.  I also had the opportunity to do a short 10-minute demo of the Raspberry Pi late Saturday night

At this point I still have to try Monodevelop and editing pictures using Shotwell, but both of those tasks look to be available.  Most of the applications have functional interfaces, but there are exceptions such as Chrome and Monodevelop.

For the second week my focus will likely be something like looking at Ubuntu testing (something I’ve wanted to do before) and continue to get accustomed to the slight changes with Ubuntu.  Overall I was pretty happy with my first week.

%d bloggers like this: