Category Archives: C#

Test Automation Framework Architecture

Test automation framework architecture efforts are often complete failures.

It’s true. I’ve worked with many companies who have given up on creating a good test automation framework architecture, because after investing a large amount of time and money and resources in doing it the wrong way, they have incorrectly assumed the entire effort is not cost effective.

In this post, I’m going to simplify the process of creating a test automation framework architecture and show you that—if you do it right—it can be a very good investment.

Test automation framework architecture basics

Let’s start off by talking about what the goals of a successful test automation framework architecture should be.

There are two goals I am interested in when creating a test automation framework:

  1. Having the ability to easily create simple automated tests that use the framework.
  2. Decoupling cosmetic application changes from the tests so that when the application changes, the tests do not all have to be updated

A good test automation framework architecture should at the very least provide these two important services. We create a test automation framework to allow us to support the creation of tests and to keep those tests from being dependent on the actual UI of our application—as much as possible.

I’m going to break down these goals just a little more to make sure we are all on the same page.

test automation framework thumb Test Automation Framework Architecture

Creating simple automated tests

First, we’ll start with having the ability to easily create simple automated tests that use the framework. Why do we care about this goal? And why would this be the responsibility of the framework?

I have found that one of the biggest failure points of test automation efforts is test complexity. The more complex the tests are, the harder they are to maintain. If tests are difficult to maintain, guess what? They won’t be maintained.

So, we really want to make sure that when we create a test automation framework architecture, we focus on making sure that test automation framework makes it as easy as possible for someone to create tests using it.

It is always a better choice to put the complexity into the framework instead of into the tests. The framework is usually maintained by developers and does not contain repeated code. But, tests are often created by QA or even business folks and the code found in tests is usually repeated across many tests, so it is vital to reduce the complexity on the tests, even if it means a large increase of complexity in the framework itself.

When I create a test automation framework architecture, my goal is to make it so the tests can read as close as possible to plain English. This requires some effort to pull off, but it is well worth it.

Decoupling the UI from the tests

Next, let’s talk about what I mean by decoupling cosmetic application changes from the tests.

This is also a vital goal of any test automation framework architecture, because if you fail to decouple the UI of an application from the tests, every single UI change in an application will cause possibly hundreds or thousands of tests to have to be changed as well.

What we really want to do is to make it so that our test automation framework architecture creates an abstraction layer that insulates the tests from having to know about the actual UI of the application.

At first this seems a little strange, especially when I tell automation engineers or developers creating an automated testing framework not to put any Selenium code into their actual tests.

All of the Selenium examples show you creating tests that directly use a web browser driver like Selenium, but you don’t want to write your tests that way—trust me on this one.

(By the way, I haven’t found a good book on creating an actual test automation framework architecture—I’ll probably write one—but, for now if you are looking for a good book on Selenium that starts to go into the topics I discuss here, check out Selenium Testing Tools Cookbook.)

Instead, what you want to do is to make it so the test automation framework is the only code that directly interacts with the UI of the application. The tests use the framework for everything they want to do.

So, for example:

Suppose you are creating a simple test to check to see if a user can log into your application.

You could write a test that looks something like this: (C# and Selenium in this example)

var loginInput = driver.FindElement(By.Id("txtUsername"));

var passwordInput = driver.FindElement(By.Id("txtPassword"));

var loginButton = driver.FindElement(By.Id("btnLogin"));

But, what is going to happen when you change the ID of your “User Name” field? Every single test that uses that field will break.

On the other hand, if you properly create a test automation framework architecture that abstracts the UI away from the tests themselves, you would end up with a much simpler and less fragile test, like this:


Now, if the ID of your “User Name” field changes, you’ll just change the code in your automated testing framework in one place, instead of changing 100 tests that all depended on the specific implementation of the UI.

A simple test automation framework architecture

Once you understand those two very important goals and why they are important, it is easier to think about how you should design a test automation framework architecture.

I’ve created quite a few test automation framework architectures, so I’ll give you a basic design I use for most of them.

Take a look at this diagram:

test automation framework architecture thumb Test Automation Framework Architecture

Here you can see that there are four layers to my test automation framework architecture.

Frist, we have the browser layer or the web app itself. This just represents your actual application.

Next, we have the Selenium or web driver layer. This layer represents your browser automation tool. Selenium is basically just a framework for automating a browser. It doesn’t know anything about testing, it is an API that lets you interact with the browser programmatically. (By the way, you don’t have to use Selenium. I just use it as an example here, because it is the most popular browser automation framework.)

After that, we have the framework layer. This is the actual framework you create which uses Selenium, or whatever web driver you want, to actually automate your application. The framework is acting as an abstraction between your application and the tests. The framework knows about the UI of your application and how to interact with it using Selenium. It is your job to create this layer.

Finally, we have the actual tests. The tests use the framework to manipulate your application and check the state of the application. These tests should be simple to understand and should not have to know anything about the actual implementation of the UI of your application. These tests should rely on the framework to give them the ability to do whatever they need to do in your application.

Now what?

Obviously, creating a test automation framework architecture is more complicated than what I have shown you in this article, but with these basics you should be off to a good start.

If you want a more in-depth and detailed explanation as well as an example of how exactly to create a full test automation framework architecture, you might want to check out my Pluralsight video on the topic:

Creating an Automated Testing Framework With Selenium

I also frequently blog about test automation topics and other topics related to becoming a better and more profitable software developer.

Sign up here to make sure that you don’t miss any of my posts and get access to the content I only share with my email list. (Don’t worry I hate spam as much as you do.)

If you have any question, post them in the comments below.

Why We Need More Complex Programming Languages (Yes, You Heard Me Right!)

My daughter is learning how to read right now.  As I was thinking about this blog post, I just walked past my wife and her working on some very basic reading skills.  It is quite a bit of work to teach her everything she needs to know to read and write the English language.

In fact, it will be years of hard work before she’ll actually be able to read and write with any measure of competence—at least by our adult standards.  We tend to take language for granted, but spoken and written languages are difficult—exceptionally difficult.

Even as an adult, writing this post is difficult.  The words don’t flow perfectly from my mind.  I strain to phrase things in the proper way and to use the proper punctuation.

But, even though it is difficult to learn a written language, we make sure our kids do it, because of the high value it gives them in life.  Without the skills to read and write a language, most children’s future would be rather bleak.

The more and more I thought about this idea, the more I realized how simple programming languages are compared to the complexity of an written or spoken language.

girl reading thumb Why We Need More Complex Programming Languages (Yes, You Heard Me Right!)

The argument for more complexity

The irony of me arguing for more complexity and not less doesn’t escape me, but even though I strive to make the complex simple, sometimes we do actually need to make things more complicated to achieve the best results possible.

I’ve thought about this for a long time and I believe this is the case with programming languages.  Let me explain.

Before I get into programming languages specifically, let’s start off by talking about human languages.

I speak and write English.  English is considered to be the language with the largest total vocabulary and also one of the most difficult languages to learn, because of the flexibility in the ways in which you can compose sentences with it.

It is very difficult to learn English.  I am fortunate that I am a native English speaker and grew up learning English, but for many non-native English speakers, the language continues to be a challenge—even years after they are “fluent” in the language.

There is a huge benefit though, to being fluent in the English language—expressiveness.  I don’t profess to be an expert in foreign languages—I only know a little bit of Spanish, Brazilian Portuguese and Japanese, myself—but, I do know that English is one of the most expressive languages in existence today.  If you want to say something in English, there is most likely a word for it.  If you want to convey a tone or feeling with the language—even a pace of dialog, like I just did now—you can do it in English.

As I said, I can’t speak for other languages.  But, having lived in Hawaii, I can tell you that Hawaiian is a very small language and it is difficult to express yourself in that language.  Sign language is another example of a very small language which is fairly easy to learn, but is limited in what it can convey and the way it can convey it.

I say all this to illustrate a simple point.  The larger the vocabulary of a language and the more grammatical rules, the more difficult it is to learn the language, but the greater power of expressiveness you have with that language.

Breaking things down even smaller

I promise I’ll get to programming languages in a little bit, but before I do, I want to talk about one more human language concept—alphabets or symbols.

The English alphabet has 26 letters in it.  These 26 letters represent most of the sounds we use to make up words.  26 letters is not a small number of characters, but it is not a large amount either.  It is a pretty easy task for most children to learn all the letters of the alphabet and the sounds they make.

The text you are reading right now is made up of these letters, but have you ever considered what would happen if we had more letters in the alphabet?  For example, suppose instead of 26 letters, there were 500 letters.  Suppose that we made actual symbols for “th”,”sh”,”oo” and so forth.  Suppose we made the word “the” into a symbol of its own.

alphabet thumb Why We Need More Complex Programming Languages (Yes, You Heard Me Right!)

If we added more letters to the alphabet, it would take you much longer to learn the alphabet, but once you learned it you could read and write much more efficiently.  (Although, I’d hate to see what the 500 letter keyboard would look like.)

My point is that we are trading some potential in the expressiveness we can pack into a limited number of symbols for some ease in learning a useful set of symbols.

As you were reading this, you might have thought that this is exactly what languages like Chinese and Japanese do—they use a large number of symbols instead of a small alphabet.  I don’t know enough about these languages to know the answer for sure, but I’d bet that it is much easier to read a Chinese or Japanese newspaper than it is to read an English one—or at least faster.

We could take the same exercise and apply it to the number system.  Instead of using base 10, or having 10 symbols in our number system, we could have 100 or even 1000.  It would take a long time to learn all our numbers, but we’d be able to perform mathematical operations much more efficiently.  (A smaller scale example of this would be memorizing your times tables up to 99 x 99.  Imagine what you could do with that power.)

What does all this have to do with programming languages?

You really are impatient aren’t you?  But, I suppose you are right.  I should be getting to my real point by now.

So, the reason why I brought up those two examples before talking about programming languages is because I wanted you to see that the vocabulary and grammar of a language greatly influence its expressiveness and the basic constructs of a written language, greatly influence its density; its ability to express things concisely.

Obviously, we can’t directly map human written languages to programming languages, but we can draw some pretty powerful parallels when thinking about language design.

I’ve often pondered the question of whether or not it is better to have a programming language that has many keywords or few keywords.  But, I realized today that was an over simplification of the issue.

Keywords alone don’t determine the expressiveness of a language.  I’d argue that the expressiveness of a language is determined by:

  • Number of keywords
  • Complexity of statements and constructs in the language
  • Size of the standard library

All of these things combined work together to make a language more expressive, but also more complicated.  If we crank up the dial on any one of these factors, we’ll be able to do more with the language with less code, but we’ll also increase the difficulty of learning the language and reading code written in that language.

Notice, I didn’t say in writing the language.  That is because—assuming you’ve mastered the language—the language actually becomes easier to write when it has more constructs.  If you’ve ever run across someone who is a master of Perl, you know this to be true.  I’ve seen some Perl masters that could write Perl faster than I thought possible, yet when they came back to their own code months later, even they couldn’t understand it.

Looking at some real examples

To make what I am saying a little more concrete, let’s look at a few examples.  I’ll start with C#, since it is a language I am very familiar with.  C# is a very expressive language.  It didn’t start out that way, but with all the keywords that have been added to the language and the massive size of the base class libraries, C# has become very, very large.

C# is an evolving language.  But, right now it has about 79 keywords.  (Feel free to correct me if I am wrong here.)  As far as languages go, this is pretty large.  In addition to just keywords, C# has some complex statements.  Lambda expressions and LINQ expressions immediately come to mind.  For someone learning C#, the task can be rather difficult, but the reward is that they can be pretty productive and write some fairly concise code.  (At least compared to a more verbose language like C or C++.)  Java, is pretty close in most of those regards as well.

But, take a language like Go.  Go is a language with only 25 keywords.  It makes up for this by having some fairly complex language constructs and having a pretty robust standard library.   When I first learned Go, it took me perhaps a week to feel like I had a pretty good grasp of the language.  But, it took much longer to learn how to use Go properly.  (And I still have plenty to learn.)

At the far end of the spectrum, we have languages like BASIC.  Different BASIC implementations have different keyword counts, but most of them are pretty low and the constructs of the language are very simple.  BASIC is a very easy language to learn.  But, because it is so easy to learn BASIC and BASIC is so simple, the average programmer quickly outgrows the capabilities of the language.  BASIC isn’t very expressive and it takes many more lines of code to write the same thing you could write in a few lines of C# or Go.

For a much more comprehensive overview of differences between programming languages, I’d recommend Programming Language Pragmatics.  It does into details about many different languages and the differences between them.

What more complex programming languages buy us

It feels really weird to be arguing for something to be more complex, since the mission of this blog is to make the complex simple, but in the case of programming languages, I think the tradeoff of increased complexity is worth the cost of extra learning time.

Consider how much more complicated the English language is than any programming language.  To be able to read the very words you are reading now, you have to understand a vocabulary of several thousand words, recognize most of those words on sight, and understand a very complicated set of mechanics which govern the grammar of the language.  There aren’t even concrete rules, much of what is “right” or “wrong” is based on context.

Yet, even with all this complexity, you are able to do it—our brains are amazing.

complex thumb Why We Need More Complex Programming Languages (Yes, You Heard Me Right!)

Now, imagine what would happen if we decided that English was too difficult of a language and that we needed to dumb it down.  What if we dropped the vocabulary down to say 200 words and we got rid of the complex rules.  What you would have is basically a Dr. Seuss book or some other early reader type of children’s book.  It would be very difficult for me to convey the kinds of thoughts I am conveying to you right now with those restrictions.

When you compare even the most complex programming language to the English language, it is no contest.  The English language is far more complex than any programming language we have ever conceived of.  I don’t know of a programming language that the average person couldn’t learn reasonably well in a year’s worth of time.  But, if you were to try and teach someone written English in a year—well, good luck to you.

If we created much more complex programming languages, we would have a much larger learning curve.  But, in exchange, we’d have a language—that once mastered—would allow us to express algorithmic intent at a level we can’t even imagine now.

Not only would we be able to express our intent more clearly and more concisely, but we’d also greatly reduce the total lines of code and potential for bugs in our software.  Less code equals less bugs.

The drawbacks

Now, I’m just playing around mentally here.  I “half” believe what I am saying, because I am just exploring ideas and possibilities.  But, even in this mental exercise of thinking about what would happen if we created programming languages as complex as written languages, I can’t ignore the drawbacks.

Obviously, the biggest drawback would be the learning curve required to learn how to program.  Learning how to program—at least how to do it well—is pretty difficult now.  I still think people make it more complicated than it needs to be, but software development is a much more difficult vocation to pick up than many other career choices.

If we created more complex programming languages, we’d have to count on many more years of learning before someone could even really write code or understand the code that is already written.  It might take 4 or 5 years just to understand and memorize enough of the language to be able to use it effectively.

We could of course combat this to some degree by starting beginners on easier languages and advancing them up the chain to more complex ones. (In fact, writing this article has convinced me that would be the best way to learn today.  We shouldn’t be starting developers with C# or Java, but instead should teach them very simple languages.)

We would probably also be forced down a smaller path of innovation, as far as programming languages go.  The world can support 100’s of simple programming languages, but it can’t easily support that many complex languages.  We might end up with one universal language that all programmers used.  A language of this size would be very unwieldy and hard to advance or change.  It would also take a massive effort to create it in the first place, since written languages developed naturally over hundreds of years.

That’s enough fun for now

After writing this article my brain is hurting.  I’ve been considering writing this post for awhile, but I wasn’t sure exactly where I stand on the issue.  To be completely honest with you, I still don’t.  I do think that more complex programming languages would offer us certain benefits that current programming languages do not, but I’m not sure if the drawbacks would be worth it in the end or even what a significantly more complex programming language would look like.

What about you, what do you think?  Am I just crazy?  Is there something significant I missed here?

Oh, and if you found this post interesting and want to hear more of my crazy thoughts about software development—and a few sane ones as well, sign up here and you’ll get a weekly roundup of my posts and some other content I only send out to subscribers.

An MVC4, iOS And Android App With ServiceStack, Xamarin and C#

A bit late getting this out, but I published a new course for Pluralsight.

An MVC4, iOS And Android App With ServiceStack, Xamarin and C#

This course was really fun to create.  I got to use several of my favorite technologies.

2013 08 19 16 52 05 thumb An MVC4, iOS And Android App With ServiceStack, Xamarin and C#

Here is the course description:

It can be very difficult to build a cross platform application that will work on the web as well as popular mobile platforms like Android and iOS.

In this course, I’ll take you through the complete process of creating an application that works on each of the platforms and uses a REST based backend API to share data and business logic—all using C#.

We’ll start off this course by learning how to build a REST based API using the popular open source framework ServiceStack. I’ll show you how easy it is to get ServiceStack set up and even how to store data for the API using a Redis database.

Next, I’ll show you how to create an ASP.NET MVC 4 application that uses the REST service we built to display it’s data and implement it’s logic. We’ll learn how to use JQuery to make AJAX calls to a REST based API from within our MVC 4 application.

Then, we’ll learn how we can use C# and the .NET framework to build an Android application using the Xamarin tools. We’ll use the same REST API, we created earlier and build a real native Android application that is able to consume that API for implementing its logic and displaying data.

Finally, I’ll show you how to do the same thing for an iOS application. We’ll again use C# to build a real native iOS application with the Xamarin tools and learn how to consume REST based web services from iOS.

So, if you are a C# developer and don’t want to have to learn several other programming languages to build cross platform applications; you’ll definitely want to check out this course. By the end of this course, you’ll have the skills you need to be able to implement an end-to-end cross platform solution complete with a REST based API backend all in C#.

Getting Started With Glimpse In ASP.NET MVC

If you are using ASP.NET, especially if you are using ASP.NET MVC, you need to be using Glimpse.

I’m currently working on a more exhaustive Pluralsight course on Glimpse,  (the course is now live!) but I thought I’d write up a quick getting started tutorial here.

What is Glimpse?

Perhaps you haven’t heard of Glimpse yet, or you are just a little unsure of exactly what it is.

Glimpse is basically an open source and free diagnostics platform for the web.  Right now it works best with ASP.NET and especially ASP.NET MVC, but it can be extended to other platforms as well.  There is already work started for a PHP version and even a Python port.

What Glimpse essentially does is let you see diagnostics information about what is happening on your server directly in your page through a small diagnostics window completely rendered in JavaScript.

Out of the box, Glimpse can show you all kinds of information about your MVC application, like what routes are registered, what the flow was through the MVC pipeline and how the models were bound.

(BTW, if you are looking to brush up on your ASP.NET MVC 4 skills or learn about ASP.NET MVC 4, I recommend Professional ASP.NET MVC 4.  Great book, top notch authors.)

Here is what the Glimpse window looks like on a page.

Home Page   My ASP.NET MVC Application   Google Chrome 2013 05 19 09 30 58 thumb Getting Started With Glimpse In ASP.NET MVC

Glimpse is also fully extendable.

There are already plugins for Entity Framework, NHibernate, Ninject and many, many more

The best part about Glimpse is how easy it is to get setup.

I’ll walk you through the steps below.

Step 1: Get Glimpse from NuGet

All you have to do to get Glimpse installed is simply either:

  • Open up the Package Manager Console and type “Install-Package Glimpse.Mvc4” (or “Glimpse.AspNet if you aren’t using MVC)
  • Or, right click on your references, select Manage NuGet Packages, then search for Glimpse and find the appropriate Glimpse package.

GlimpseTutorial   Manage NuGet Packages 2013 05 19 09 44 14 thumb Getting Started With Glimpse In ASP.NET MVC

One you’ve done that, Glimpse will automatically add a few entries to your web.config for you.

2013 05 19 09 46 18 thumb Getting Started With Glimpse In ASP.NET MVC

2013 05 19 09 47 06 thumb Getting Started With Glimpse In ASP.NET MVC

2013 05 19 09 49 21 thumb Getting Started With Glimpse In ASP.NET MVC

Step 2: Turn on Glimpse

Turning on Glimpse is super easy.

Just launch your app and navigate to glimpse.axd.  Then, click “Turn Glimpse On” to set a cookie that will tell the Glimpse component running on the server to send you Glimpse data.

2013 05 19 09 52 16 thumb Getting Started With Glimpse In ASP.NET MVC

Go to glimpse.axd

Glimpse   Configuration Page   Google Chrome 2013 05 19 09 52 38 thumb Getting Started With Glimpse In ASP.NET MVC

Turn it on!

It’s that simple!

Step 3: Fire it up

Now all you have to do is navigate to any page in your application and you’ll see this little icon at the bottom right hand corner of the screen:

2013 05 19 09 55 28 thumb Getting Started With Glimpse In ASP.NET MVC

If you click the icon, you’ll see the Glimpse panel, which currently looks similar to the Chrome Dev Tools panel.

Home Page   My ASP.NET MVC Application   Google Chrome 2013 05 19 09 57 54 thumb Getting Started With Glimpse In ASP.NET MVC

Using Glimpse

Each tab contains different diagnostics information about your application.

This data can be extremely helpful in troubleshooting problems and learning about exactly what is going on inside of MVC.

You can also find plugins that can be easily installed from NuGet.

For example, if you add the Entity Framework plugin, you’ll start seeing a tab that shows data about EF queries, like this:

2013 05 19 10 04 46 thumb Getting Started With Glimpse In ASP.NET MVC

I’m pretty excited about Glimpse and its future.  Anthony van der Hoorn and Nik Molnar, the two creators and main maintainers for Glimpse, have done an excellent job transforming how we get diagnostics information for web applications.

One of the things I find most exciting about this platform is how easy it is to extend.  In my upcoming Pluralsight course, (the course is now live!) I walk you through creating a Glimpse plugin, which is surprisingly easy.

So if you haven’t checked out Glimpse, what are you waiting for?  Go do it now, it will take you about 5 minutes to get setup.

What do you think?  Are you using Glimpse already?  Post a comment and let me know.

My YouTube video for the week: (This is not an ad!)

Dealing With Burnout

And here is the weekly Get Up and Code episode:

Implicit and Explicit Conversion Operators in C#

Recently I stumbled upon a pretty interesting feature of C# that I either neglected to really pay attention to before or just had entirely missed.

It is definitely debatable whether or not one should even use this feature, because it is likely to result in some confusing situations by someone reading your code even if they are aware of the feature’s existence.

Take a look at this code

Let’s look at an example that might look a bit strange.

What would you think if you stumbled upon this code?

Book book = new Book("Code Complete");
XDocument document = book;


book thumb Implicit and Explicit Conversion Operators in C#

What if I told you that Book does not inherit from XDocument?

In this case a custom implicit casting is happening because of an implicit conversion operator I created on Book.

Here is how it is defined:

public class Book
        private readonly string title;

        public Book(string title)
            this.title = title;

        public static implicit operator XDocument(Book b)
            // Code to convert the book into an XML structure
            return new XDocument();

        protected List<Page> Pages { private get; set; }


What is happening in this case is that the compiler is noticing that I am trying to assign a Book object to a variable of type XDocument and that I have defined an implicit operator to allow that conversion.

By defining this implicit conversion operator I can assign any Book to an XDocument and it will execute the code defined in my implicit operator method to return an XDocument.

Backwards as well

I can also make the conversion the other way.

XDocument document = new XDocument();
Book book = (Book)document;


You can see here that I am doing something a bit different though.  In this case I am explicitly casting the XDocument into a Book.

I could have used implicit conversion, like the previous example, but not all XDocuments can automatically be converted to Books, so I wanted to make it allowed only if someone explicitly used the casting operator to perform the cast.

Here is what that code looks like:

 public static explicit operator Book(XDocument d)
	 // Code to convert the XML document into a book
    return new Book("");



You can only use the implicit and explicit operators on classes that you have defined.  You can’t use them to extend existing classes to add automatic conversions.

Also the conversions can’t chain automatically.  If you have a conversion to type a Dog to a Cat and a Cat to a Mouse, you can’t assign a Dog directly to a Mouse.

Should I use it?

Now that is a tough question.  I have some mixed thoughts on actually using this feature.

My biggest problem with it is the discoverability.  When I look at code that is assigning a Book to an XDocument, I don’t immediately know where to look for the code that is allowing that assignment.  The code could actually exist in either the Book class or the XDocument class.  (We happen to know in this case that XDocument is a .NET class, so it’s not going to be there, but where you have to user defined classes, you can’t be sure.)

If I didn’t know about implicit and explicit operator overloads, I would be even more puzzled.

My other reservation is that in most cases it is not immediately obvious what exactly is happening.

  • Are we getting a copy of Book that is representing an XML structure?
  • Are we getting a raw XML document that could be populated with Book data?
  • Are we losing data here?

I can look at the method to figure out what is going on, but that makes the code that is using the implicit or explicit conversion less readable by itself.

It seems to me in that case having a method off of Book called ToXDocument() would make things at least a bit more clear.

On the other hand, I can definitely see some benefits to using these operators to make code more succinct and to make types that have obvious conversion easier to work with.

Consider having classes that represent temperatures in Celsius and Fahrenheit.  In those cases implicit conversion operators between the two formats makes intuitive sense.  We can also be pretty confident that the conversion would not result in a data loss.

termo thumb Implicit and Explicit Conversion Operators in C#

General guidelines

In general, my recommendation would be to avoid defining implicit and explicit operators because it is likely that most developers reading your code will be confused by them and in most cases you are not adding much value.

I would say that you should only use implicit and explicit operators when the conversion between two types is very clear because they are just different ways of representing the same value.

Although I can see the cases for other uses of the operators, it seems like there the usage is more likely to cause confusion than bring clarity.

To me an equal sign means assignment, I do not often think of it to mean conversion.

I could of course be wrong about my thoughts on implicit and explicit operators, but as of yet I haven’t seen it in the wild, so if you have some good examples of where it makes sense to use this feature, please let me now.

If you like this post don’t forget to Follow @jsonmez or subscribe to my RSS feed.

Introduction to MonoGame

I’ve been playing around quite a bit with MonoGame lately and thought I would take some time to write a bit about it and talk about how to get started.

I’m also currently working on a Pluralsight course on cross platform development with MonoGame.

monogamelogo100x100 thumb Introduction to MonoGame

What is MonoGame?

Well, if you are familiar with XNA, then you already know what MonoGame is.

If you are not familiar with XNA though, it is basically a game development framework that allows for creating games quickly without having to write all that repetitious code that all games need.

Basically it makes creating games more about the game and less about the technical details.

The only problem with XNA is that it only really works for Windows, XBox360 and Windows Phone 7.  If you want to create a game on Android and iOS, you can’t use XNA.

This is where MonoGame comes in.  MonoGame is an open source port of the XNA framework that can run on many more platforms that Microsoft’s XNA.

Great, so what does this actually mean?

Well, if you are interested in game development, especially if you are interested in game development for the most popular platforms today, MonoGame might be able to help you to write pretty close to the same exact code and have it work on Android, iOS, Windows 7, Windows 8, Windows Phone 7, MacOS, XBox 360, Linux and the new Playstation console.

That is pretty awesome!  Especially if you are trying to monetize your effort.

In my mind MonoGame helps overcome two huge barriers to getting into game development.

  1. Difficulty of monetizing the effort.  By allowing the same code to be shared on most platforms, a game developer can get paid for their effort in multiple marketplaces.
  2. Not knowing where to get started.  The XNA API is so simple to use that you can get a simple game, like a Pong clone for example, up and running in about a couple of hours.

Also, because MonoGame is basically just XNA, you can find a whole host of resources on how to develop a game using the platform.

In my upcoming Pluralsight course, I show how to create a Pong clone on Windows and then we get that game up and running on Android, iOS and Windows Phone 7, with minimal changes.

dgun 853 50 games pr h thumb Introduction to MonoGame

Getting started

It can be a bit challenging to find good information to get started in each platform using MonoGame, but the basics are located on the Github page.

For the Windows tutorial there, you can use Visual Studio instead and use the MonoGame installer.

For each platform things area slightly different, but really not all that hard.  If you want to have your game run in Android and iOS, you’ll need Mono for Android and MonoTouch respectively.

For Android development, you can use Visual Studio as long as you have Mono for Android installed and all you really need to do is link your files from your Windows project and create a small bit of startup code in an Android Activity to start the game.

For iOS development, you will need to use MonoDevelop, which is packaged with the install of MonoTouch.  MonoTouch itself uses XCode and the iPhone SDK, so you have a bit more installing to do there, but the idea is pretty much the same.  One you have MonoTouch running on your Mac, you can link over the files from your Windows project, add a small bit of startup code, and you are up and running.  (You’ll also need to download the actual MonoGame source code to add to your project, since there isn’t an installer for Mac currently.)

Xamarin also has a seminar they did on MonoGame to help you get started.

True cross platform development, finally

At least for game developers.  For other applications in the mobile space, there are some solutions that help you share your code, but nothing that really allows you to have near 100% portability without a big sacrifice.

I was pretty amazed the first time my game just ran on my Android and iOS devices with virtually no changes.

I’d definitely encourage you to check out MonoGame and stay tuned for my Pluralsight video on the topic, where I will go through all the details of creating a game and getting it running on most of the major platforms.

Book Review: C# in Depth Second Edition

Been staying pretty busy lately, so I haven’t been reading all that much, but I did just finish reading C# in Depth Second Edition by Jon Skeet.

skeet2 cover150 thumb Book Review: C# in Depth Second Edition

This book is basically a coverage of all the major features of the C# language that have changed since the first edition of C#.

It is a pretty long book, but it covers a pretty large topic and it does indeed cover it “in depth.”

I debated whether it was worth my time to read this book, since I already had a good grasp of most of the C# language, but I am definitely glad I did.  There are many very detailed concepts that Jon does an excellent job of explaining which make other language concepts seem much simpler.

The book is basically a forward progression through the advances of C# through each major revision.  Jon does an excellent job of presenting not just the what, but the how and whys for each language revision.

The developer that has at least a decent knowledge of the C# language will get the most out of this book, as it can get a bit tricky and complex at times.  Definitely is a book for advanced developers as well, who will most assuredly learn something about the language they didn’t know.

If you’ve watched any of my Pluralsight courses, you know that I like to teach in a very informal and conversational way, and it seems Jon Skeet also takes this approach and makes this highly technical book quite readable.


  • Very excellent and detailed coverage of language features of C#.
  • Excellent verbal illustrations to help simplify some complex topics and make them memorable.
  • Down to earth conversational approach to the material makes it a joy to read.
  • The coverage on LINQ is phenomenal.
  • Book builds in progression on previous examples and chapters very naturally.
  • It is very obvious great detail went into making and planning out this book.  Rare to see today.


  • Coverage of dynamics and DLR is a bit dry.  The topic is very complex and I felt like the book launched in a bit too fast.
  • Sometimes I felt like Jon was a bit too objective in presenting his opinion.  I generally trust the values and opinions of a skilled developer like Jon Skeet, so I would rather have his opinions be presented a bit more firmly in the book.

What I learned:

First off, a whole lot more than I would have expected.

There are many aspects to the C# language that I thought I understood fairly well, but had never turned down one dark little corridor.  This book made me turn down those corridors and face the demons there.

Specifically, I thought I understood how LINQ providers worked.  I never really looked into one, because I had an assumption about how a LINQ provider would work based on what I knew of the language.  I found out that I was wrong in my assumptions and I now have a much more thorough understanding of LINQ and how all the pieces of the language fit together to make it work.

I also learned quite a bit about dynamics and the DLR.  Although it was a bit painful, I felt like the book got me to reconsider my stance on dynamics just a bit and consider some places in the statically typed C# language where they might make sense.  (Understanding how dynamics work reduced them to the same level as any reflection based code in my mind.)

Overall, I would highly recommend this book.  My only two negatives about the book should not dissuade you from reading it.  A beginner or intermediate C# developer could easily raise both their skill level and knowledge of C# considerably just by reading this book, and any advanced C# developer should have plenty to learn from it as well.

Types of Duplication in Code

One of the biggest reasons to refactor code is to eliminate duplication.  It is pretty easy to introduce duplication in our code either unintentionally or because we don’t know how to prevent or get rid of it.

The three types of duplication

I’ve found that there are three basic types of duplication that we can eliminate from our code that successfully build on each other.

  • Data
  • Type
  • Algorithm

Most developers tend to get stuck at the data level, but in this post, I will show you how to recognize type and algorithm duplication and refactor it out of your code.

duplicate content thumb Types of Duplication in Code

Data duplication

The most basic type of duplication is that of data.  It is also very easily recognizable.

Take a look at these methods:

public Position WalkNorth()
   var player = GetPlayer();
   return player.NewPosition;

public Position WalkSouth()
   var player = GetPlayer();
   return player.NewPosition;

public Position WalkEast()
   var player = GetPlayer();
   return player.NewPosition;

public Position WalkWest()
   var player = GetPlayer();
   return player.NewPosition;


Pretty easy to see here what needs to be refactored.

Most developers don’t need any help to realize that you should probably refactor this code to a method like the following:

public Position Walk(string direction)
   var player = GetPlayer();
   return player.NewPosition;


In this example data is duplicated.  To be specific the string data of the direction passed into move is duplicated.  We can eliminate that duplication by creating a method that parameterizes the differences represented by that data.

Type duplication

Now, data duplication is where a majority of developers stop, but we can go much farther than that.  In many cases the difference between two methods is only the type in which they operate on.

With the use of generics in C#, we can refactor out type and parameterize this concept as well.

Look at this example:

public int FindIntMatch(int i)
   var match = (int)container.Get(i);
   return match;

public string FindStringMatch(string s)
   var match = (string)container.Get(s);
   return match;


Here we have two method that do pretty much the same thing, but they just differ on the type they operate on.  Generics gives us the ability to actually refactor out that type information just like we would with data.

public T FindMatch(T t)
   var match = (T)container.Get(t);
   return match;


By refactoring to the above method we have eliminated duplication. We have achieved this by refactoring out type.

Algorithm duplication

Without a good understanding of delegates and functional programming, few developers ever even consider refactoring out algorithm duplication, but it can be done fairly easily.

Take a look at this example:

public void GoForRun()

public void LiftWeights()


It is a pretty basic example, but it highlights the kind of duplication that I often see left in many code bases.  Delegates in C# allow us to treat functions like data.  With this ability we can easily refactor out the commonality in these two method to get something like this:

public void DoFitnessActivity(Action activity)


We could have also refactored out this duplication by using an abstract base class and having the inherited classes definite their own fitness activity, but using delegates creates a much simpler approach and casts the problem in the same light as refactoring any other type of data.

Combining them together

Often I find that several different types of duplication are present across several methods in a class.

When this is the case, it is often possible to apply data, type and algorithm duplication refactoring techniques to find the most simple and elegant solutions.

I’ve also found this is a skill that must be practiced.  When I first really started using generics and delegates in C#, I had a hard time finding uses for them, because I could not easily recognize the patterns of duplication that called for them.  But, I found over time that it became easier and easier to recognize where these techniques could be applied to reduce duplication in my methods.

I’ve also found the key to eliminating duplication is sometimes to first exaggerate it.  Often I will purposely take two methods that I know have some duplication and make them look even more duplicated in order to be able to clearly see where the duplication lies.  I may do several small refactoring steps to get to the point where it is easy to identify what data, type or algorithm is being repeated.

Wrapping Callbacks

I’ve recently had the problem of trying to display a progress dialog when executing an asynchronous operation and to dismiss that progress dialog when the operation completes.

I wanted to build a way to do this that is generic to my application, so that it would work with any asynchronous operation in order to reduce duplication of writing progress dialog logic everywhere in the code.

11 290x300 thumb Wrapping Callbacks

Looking at the problem

So here is some basic pseudo-code of the problem.

public void DoCall()

public void CallBackMethod(Result result)
    // Process result;

Now the problem with this code is that it would have to be repeated everywhere I want to make an asynchronous call and display a progress dialog.

If I want to do this in my application every time that I make an asynchronous call, I have to put this kind of code in many places in the application.

You can also see a mixing of responsibilities here.  We are handling UI related showing of a progress dialog split between an initial call and the callback.  It just seems a bit dirty to do things this way.

Breaking it down

So how can we solve this problem?

Go ahead and think of some way that you might be able to solve this.

One of the best ways that I have found to solve any problem like this is to work backwards.

Let us assume that any syntax we can think of is possible, and then only change the ideal syntax if it proves to not be possible.

What do I mean by this?

Simple, let’s come up with the way we want this code to look and we will worry about implementing it later.

It would be nice to be able to execute an asynchronous method and display a progress dialog with a one-liner, like so:

UIServiceCaller.ExecuteAsync(RemoteService.DoAsync, CallBackMethod);

If we could just do this wherever we want to make an asynchronous call and automatically have the progress dialog shown and dismissed, life would be wonderful.

Solving the problem

In order to solve this problem, we can do something very similar to a decorator pattern.

We can basically just wrap our callback method with a new callback that adds the functionality of dismissing our progress dialog.

So the idea will be that we will do the following steps in our ExecuteAsync method:

  1. Show the progress dialog
  2. Wrap our callback with one that dismisses our dialog and then executes the callback.
  3. Execute our asynchronous operation passing the new wrapped callback as the parameter.

gift wrap nature lovers easy style fabric wrapping 1211 l thumb Wrapping Callbacks

Here is what this looks like in code:

public static void ExecuteAsync(Action<Action<Result>> asyncMethod, Action callback)

   Action wrappedCallback = (r =>


This code actually looks more complicated than it really is.

You will need to understand how Action works though.  If you don’t, check out this post I did explaining Action and Func.

Understanding the solution

It can be a bit hard to wrap your head around Action of type Action of type Result.

Let me translate this to make it a bit easier.

The first parameter to ExecuteAsync is a method that takes another method as a parameter (the callback,) which takes a Result object as a parameter.

Go ahead and read that over until you get it.

So, the idea here is that we are passing in the method that is going to do the callback as the first parameter to your ExecuteAsync method.

Then we are passing in our actual callback as the 2nd parameter to ExecuteAsync.

The idea is that we are splitting apart the method and the callback it takes, so that we can insert our code to handle the dialog where we need to.

Now we can just call ExecuteAsync and pass it our method and its callback and progress dialog code will automatically be handled for us.

Building on the idea

We can expand upon this concept in several ways.

One thing we could do is also apply error handling logic to the callback wrapper method.  We could preprocess the result in some way before passing it to the callback.  This could allow us to display an error message or even retry a number of times before executing the callback.

Another thing we could do is to change the signature of the ExecuteAsync method so that it takes a type T instead of Result; this would allow us to handle any kind of return type and method, and the ExecuteAsync method would work with just about any asynchronous method call.


I’ve been so busy lately that I have neglected to write about a great platform for developing iOS applications called “MonoTouch.”

I recently released a new course on MonoTouch at Pluralsight.

I wanted to take a bit of time here to talk about MonoTouch and to tell you why you should be using it instead of developing iOS applications in Objective-C

text monotouch thumb MonoTouch

Flipping directions

gophoto 0197 scanned image 00363 thumb MonoTouch

When I first started developing with iOS, I firmly believed that the job should be done using the tools that Apple provided.

I still think it is a very good idea to learn Objective-C and how to develop an iOS application using Objective-C and XCode.

But I am convinced now that overall MonoTouch is the way to go.

Objective-C is a decent language, but it has a fairly steep learning curve for a C# or Java developer.  XCode, the IDE for developing iOS applications, is a decent IDE, but it is not nearly as powerful as MonoDevelop or Visual Studio.

The reality of the situation is that Apple’s development platform is still back in 1990.  Even though there have been some changes and growth, I firmly believe now that Objective-C and the underlying technology cannot ever catch up to .NET or Java.

I don’t say this lightly.  As I said, before I developed a fairly large application in Objective-C.  I authored a Pluralsight course on iOS development with Objective-C.  I was pretty convinced this was the way to go until I gave MonoTouch a try.

An unfair test

I really gave MonoTouch an unfair test, but it passed anyway.  I set out to learn, configure, build a MonoTouch application, and deploy it to the Apple App Store in 1 weekend.

I figured if MonoTouch could pass this test then I would immediately save more than the $400 cost for the software since the next application I was going to build was going to probably take at least a week worth of time to build in Objective-C.

MonoTouch easily passed my test and really exceeded my expectations.

The main advantage

By and far the main advantage in using MonoTouch is the language.

C#’s ability to wire up events through event handlers and delegates makes working with iOS so much easier.

There are many situations in iOS where you have to create a special class to act as a delegate for providing behavior for various iOS controls and classes.  In C#, many of these delegate classes can be replaced by a C# delegate or lambda expression.

Another really painful situation in Objective-C is memory management.  If you aren’t used to tracking memory usage it takes a bit to get adjusted to it in Objective-C.  Sure, it really isn’t that hard, but once I started working with C# to build my iOS application, I realized how much faster I could fly through the code without having to even think about it.  (The newer version of Objective-C has somewhat built in memory management, but it is not a true garbage collection implementation.)

Along with C#, you get the full power of the .NET framework.  Almost all of the base class libraries from .NET are available in MonoTouch.  (You basically have the silverlight .NET profile.)

This really comes in handy in 3 main areas:

  • Working with XML
  • Working with databases
  • Calling web services

If you try to do these things in Objective-C, it is possible, but it will hurt like hell.

Give it a shot

If you are interested in developing iOS applications and you haven’t tried MonoTouch, go give it a try.  Trust me, it is worth the effort.  One of the big factors that had me developing Android applications and shying away from iOS was the hurdle of trying to learn and work with Objective-C.

MonoTouch lets you reuse your C# skills without any extra overhead, since the application is compiled down to native ARM assembly code.

If you don’t know where to get started or want to learn a little bit more about MonoTouch, feel free to check out my course on Pluralsight.

Kudos to the Xamarin team for building such a great product!

(BTW, that photo is me flipping.  Actually it is a thing I used to call “throwing myself at the ground for dramatic effect.”)

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.