Wednesday, December 29, 2010

New Year–>Learn a New Programming Language

One mantra of the The Pragmatic Programmer is to learn a new language every year.  As a new year is upon us, I thought I'd offer why we should do this and some practical ways to begin a new journey.

Why learn a new programming language?

As software developers, we solve many of the same types of problems day in and day out, typically with the same type of solutions.  Often times we don't know a better solution is out there.  Learning a new programming language teaches you diversity, seeing things in a different light, and offering you the opportunity of solving the same problem in a new, innovative way that wouldn't have been thought of otherwise. 

When we say learn a new language, this does not mean become an expert.  The goal of learning a new language goes beyond syntax, it goes to the heart of expression and learning different ways to solving the same problem.  One may find more efficient tools or concepts in another language that one could bring to the language of their choice; port some of these new concepts over to “your” language by beginning an open source project!

Where do you start?

Start by determining which programming language you want to learn.  If you don't know what programming language to learn, check out TIOBE Software.  They released a programming community index, this might give the gears of innovation a grind. 

I'm a .NET programmer by day but I’ve heard a lot about Ruby on Rails so my curiosity got the best of me and decided to go down that route.  It's amazing to me how advanced Ruby on Rails is compared to ASP.NET MVC (Yes, I know RoR came first).  The concepts of convention over configuration, gems, scaffolding, and database migrations popularized by Ruby on Rails are huge!

I would encourage you to pick something totally out of your comfort zone (not C# to VB.NET or vice versa, this doesn't count).  If you're a .NET programmer, trying something open source like Ruby; likewise, if you're a Java developer, try out some Microsoft technologies or other open source projects. 

Learning Resources

1. Koans - teaches you the syntax, structure, and some common functions and libraries through a "path of enlightenment" and testing in order to learn a new language.

My experience with working with Koans have been great!  It's a new, exciting way to work through the basics of a new language using tests.  I'd highly recommend giving them a try!

2.  Online Media (Blogs, Screencasts, Videos, etc.) - One of the many reasons I like the Development community is their openness to share what they've learned.  Take advantage of this community by searching for "How To" blogs or "101" blog entries or videos to learn your new language and then, most importantly, give back!  You'll discover issues you need to fix or new concepts you've learned, blog about it, contribute to a forum on that language.  Help others by giving back what you've learned!  It also serves as a great reference for yourself so you don't have to fight the same battle again.

Here are a few examples to start learning:

3.  Books - a more traditional way of learning a new language but is still effective (depending on the book).  With the age of e-books and multiple monitors, tutorial or step by step books are an ideal way to learn a new language and to gather some of the new concepts.  The Pragmatic Bookshelf publishes books that are very, pun intended, pragmatic.  They leave most of the theory and rhetoric out and focus on getting you coding as soon as possible.

Here are a couple examples:

  • Agile Web Development with Rails (4th Edition) - I'm currently reading/working through this book, it's a great example of writing a Rails app using Agile methodology.  It's another good example of a walk thru but has additional explanation as the author walks you thru building a shopping cart application.
  • Seven Languages in Seven Weeks - for those overachievers out there, pick up this book and begin a fast paced journey on learning 7 languages in 7 weeks!


Practice! Practice! Practice!

Often times learning a new language can be boring because we don’t have a particular problem to practice on.  We’ve learned the basic syntax but now we want to practice our new found knowledge and apply it to different sorts of problems. 

The following are examples to put your new found knowledge to use!  The key to working through the examples is to focus on the process, not the solution.  Focus on both syntax and the thought process behind it and, most importantly, focus on what you are learning through the process!  This is how we develop diversity!!

1.  Code KataDave Thomas has written a number of problems  that are worth trying.  Some examples include word chains, Klondike, and anagrams.

2.  Ruby Quiz – this site has sample quizzes based on, you got it, Ruby.  There are also suggested solutions that are implemented in Ruby.  However, this can be easily adapted with whatever language you are learning.  Examples include Paper Rock Scissors, Numeric Maze, and Dice Roller.   Remember, it’s the process, not the solution that counts!

3.  Project Euler – these are primarily mathematical/computer programming problems.



  • Learning a new language is fun but can be frustrating at times.  I’d encourage you to time box some of these learning activities.  Use the Pomodoro Technique where you practice for 25 minutes, then take 5 minutes off.  There are many apps out there that can help facilitate this.
  • Start small!  Don’t expect you can write a huge complex application out of the gate.  Realize that learning is a process and needs to be practiced!
  • Don’t focus on just learning the new syntax.  Immerse yourself in the new thought process of the new language.
  • Teach your new found knowledge with other developers who will listen!  If no one will listen, and even if they do, blog about your experience!

I hope that with the coming new year, you'll add one more New Year's Resolution (except you’ll keep this one): learn a new programming language!  It will pay back in ways you've never thought before!

Wednesday, December 22, 2010

Driving Technical Change Book Review

How do you drive technical change within your organization?  This is the key question that Driving Technical Change by Terrence Ryan answers.  We've all been there, we want to improve things in our environment, albeit technical tooling or processes to make our lives easier but often times receives resistance from skeptics.  Ryan categorizes these skeptics into the following categories (the Uninformed, the Herd, The Cynic, The Burned, The Time Crunched, The Boss, and my personal favorite, the Irrational).  He then goes on to explain different techniques in order to work with each kind of skeptic and finally wraps it up with a strategy on how to drive this change.

This book was an easy, practical, and fun read.  We, as developers, discover new tools or techniques to improve the developer's quality of life but lack a pragmatic way to communicate as a way to adopt that change.  As you read through the book, you'll put faces with the skeptics.  Imagine how you can work with them (ideally, not at them) to show them how this new tool or technique can improve their quality of life.  This book is great for building your arsenal with tools on how to better collaborate with others and how to drive technical change within your organization.

I have a friend who is passionate about Agile and Scrum but is perceived as not having good communication skills and not being able to collaborate with his peers in an effective way.  After I read this, I immediately recommended this book to him because it will help him see things in different perspectives on techniques on how to deal with different skeptics. 

Remember that a leader leads and a manager manages.  You don't have to have a manager title to lead others (although sometimes it helps).

Thursday, December 16, 2010

Scrum of Scrums

We have 3 application specific agile teams underneath one large product.  There exists a need for cross team communication, that is where the Scrum of Scrums comes in.

What is the Scrum of Scrums?
Scrum of Scrums (SOS) is a daily standup comprised of the Scrum Master from each team in order to facilitate cross team communication.
SOS occurs after all agile teams have completed theirs.  We ask the same questions as in an agile team stand up but on a team level instead of an individual level:
1.  What did you do yesterday?
2.  What are you doing today?
3.  What, if any, roadblocks exist?
4.  One additional question:  team ideas or gauges of teams feedback.

At the end of the iteration, we have our morning Iteration Retrospective and Planning Meeting <LINK>.  That afternoon, the SOS will meet to compose an e-mail with each team's action items.  One Scrum Master will e-mail everyone (all teams) with all action items, if a team member has questions, they will be encouraged to speak with their Scrum Master.  This serves as one point of contact and also documentation of the action items.
For us, this has been a good form of cross team communication and has also spurred conversation/ideas that would effect all teams such as changing Source Control Versioning System or blocks of code that would effect an underlying architecture.

Additional Resources
Jerrel Blankenship Blog

Monday, December 13, 2010

My First HTPC Build Experience…

I decided that it’s time to build my first Home Theatre PC (HTPC).  I’ve built my own PCs in the past for development and such but now was the time to build an HTPC.  This HTPC Guide helped a lot in determine specs.

I had two big dilemmas: Intel Vs. AMD and SSD vs. SATA drive.

I chose AMD purely based on cost (as you’ll see below).  I decided I could get a much bigger bang for my buck going with AMD.

SSD vs. SATA drive – I decided that SSD was still expensive and I wanted to keep this build to a small financial footprint so I went with the SATA drive.

I decided upon this build:

Case nMEDIAPC HTPC 5000B $54.99
Power Supply COOLER MASTER Elite 460 $29.99 + $1.99 Shipping
Blu-Ray Player LITE-ON Black 4X BD-ROM $39.99
Motherboard MSI 785GM-P45 mATX Motherboard $20.00 – $20.00 MIR (bundle deal with Processor)
CPU AMD Athlon II X4 640 3.0GHz Processor $95.99
Hard Drive Samsung HD103SJ Spinpoint F3 Hard Drive – 1 TB, 7200RPM, 32 MB, SATA-3G $59.99
RAM Corsair 4GB DDR3 RAM – PC10666 $69.99 – $20 MIR
Wireless Keyboard/Mouse Gearhead Wireless Desktop | KB3750W $39.99
  Sata Cable 18” $4.99

Total (After Rebates)


*Note:  Prices are subject to change as I ordered some of the components on Black Friday.

Since I had a copy of Windows 7 64 bit Ultimate that I’ll be using as my OS.  I setup a 60GB partition and installed Win 7 using a USB Flash Drive since I was short a SATA cable (which I got later).  The installation went smooth, the only hiccup was making sure you change your boot drive to your hard drive after the first reboot or the system will read from the Flash Drive and want to setup Windows again.  After I setup the OS, I connected it to my Samsung 52” television via the onboard HDMI, everything went without a hitch!

I installed XBMC Camelot (version 9.11) and learned a couple gotchas with XBMC:

1.  Do not install XBMC using Remote Desktop, it needs to be installed on the box directly. 

2.  XBMC will not open in an RDC session, you’ll need to be directly on the box to open it.

3.  If you are using IMDB as your scraper and using XBMC Camelot, you’ll need to update your IMDB xml file (XBMC\system\scrapers\video) to this one.  If you don’t update, your movie titles will not show in the library.

I’ve had this build running for the last few days and it’s quiet.  The loudest component seems to be the optical drive which I don’t use that much so I’m fine with it.  It will not disturb my movie watching!  I’m also on the lookout for a better input device to replace the wireless desktop I have.  I love the smaller keyboard but the separate mouse is cumbersome for navigation when you’re sitting on the couch.

For now, I’ve decided not to put in a TV tuner card due to my television viewing habits.  I can expand that later if I see there’s a need for it but for now I wanted a good, inexpensive system.

Overall, it was great experience and I’m going to enjoy watching what I want to watch, when I want to watch it!

Friday, November 26, 2010

Setting Up a Dev/Test Environment for PayPal Instant Payment Notification (IPN)

So you have a web site where you want to integrate PayPal IPN in a Windows environment?


1. Obtain Public IP address and (optional) get a free DNS name
2. Create web site on your local computer with an IPN Handler
3. Configure Router and Windows Firewall
4. Setup a PayPal Test Account and test IPN from PayPal

Obtain Public IP address and (optional) get a free DNS name

PayPal needs to access your web site from the internet and thus needs a public IP address or a DNS name.
Two Options:
1.  Public IP Address you can find at What is My IP Address?
2.  Free DNS name - go to DynDNS and sign up for an account.  You'll need to install a service on your test computer so when your dynamic IP updates, it will notify DynDNS so they will be in sync.  You'll end up with a name such as

Create Web Site on your Test Machine

Create a web site on your local computer in IIS that has an IPN handler aspx page.  There are a number of already written IPN handlers that you can use or tweak:
C# IPN Handler -
C# PayPal IPN Class -
Upload these files to your website as well as a dummy default html page, this will be used for test purposes only.


Configure Router

Now that you have a public url (, you need to configure your router to drive traffic to your site.  In your router setup you need to use port forwarding or virtual server to re-route port 80 traffic to the internal IP address of your test box.  If your web site is on another port than port 80, configure your router to point to the port that your website is on. 

PayPal IPN does not work with urls with port numbers in them.

Once you have the router configured, you need to open up port 80 in your Windows Firewall.  Check this article out:  Here's a good article that explains how to do that: How to configure the new Windows Server 2008 advanced firewall MMC snap-in

If you have access to an outside network, once the router is configured, try navigating to your web site page to verify you can access it.


Setup a PayPal Test Account

PayPal has a sandbox that you can utilize for free to simulate payments.  Sign up for a free account, all you need is a valid e-mail address.  Once you log in, you'll see the following screen:


Click on the "Instant Payment Notification" link.  You'll have to enter your IPN Handler URL from the site you've created.  Running this simulation will post back to your public URL and verify that you IPN code is (hopefully) working correctly.  PayPal will throw an error if it can't hit your URL. 

*Note that you can NOT have a port number in your IPN Handler URL.  If you include a port number, PayPal will thrown an error stating that it can not hit the URL. 

Happy Programming!

Additional Resources:

-How to Setup PayPal IPN Test Environment

Wednesday, October 13, 2010

Agile Retrospective Example

We have a one week iteration that starts on Wednesday.  Every Wednesday morning we do our retrospective and our planning meeting back to back.  This is the agenda that we use for our retrospectives and will hopefully serve as an idea generator for yours.

The Scrum Master is responsible for making everyone feel safe and organizing and facilitating the meeting.  Safety and preparation are key and will result in a smoother retrospective. 

In your retrospective, make sure everyone feels they are in a safe environment.  Without safety, members have a tendency to not speak up.  One way to foster a safe environment is by having everyone sit in a chair in a circle with no tables.  This represents no barriers between you and your teammates.  If individuals not on your team are attending your retrospective and do not contribute to a safe environment, ask them to not attend but that you’ll review the retrospective with them later.  This allows communication between those individuals but also allows topics to be discussed openly.

Before the meeting begins, have post it notes handed out, extra pens available, and any other needed material ready for the taking in addition to the circles in "The Soup" drawn on a whiteboard (more explanation to come).  The more prep work that is done at the beginning, the smoother the meeting will go.

At a high level, here's the agenda for our retrospectives:

1.  Set the stage
2.  Gather Data
3.  Generate Insights (The Soup)
4,  Decide What To Do (Action Items)
5.  Close the Retrospective (Thanks)

Set the Stage

Welcome the team to the retrospective and go over the agenda items.  During this stage, we also review the swim lane board to make sure it is accurate.  You'll undoubtedly have someone say, "Oh, that's done", so a quick look at the board is useful. 

Gather Data

First, we want to gather data on how the iteration went.  We want to get each team member's feel from both a technical and process aspect on how the iteration went.  What problems arose, how can we address them, and, most importantly, what are measurable action items can we do to improve the situation?  We do two activities: the Happy/Sad, and the Good/Confusing/Painful activity as described below:

Happy/Sad Activity
Purpose:  Get a general feel on the team's morale of the iteration.  We do this first so that this represents one's own personal feelings on how the iteration went and does not allow other team members to influence your decision.
Material:  Whiteboard, pen
Time:  5 - 10 minutes
Process:  The Scrum Master will ask the team "Were you happy or sad with how this iteration went?" then each member will respond and the score will be tallied.  A team member should not defend their answer, the reason(s) should be revealed in the second activity.
Good/Confusing/Painful Activity 
Purpose:  Gathering data on went well versus what didn’t and what was confusing
Materials:  Whiteboard, 3 different colored post it notes, Pens
Time:  30-45 minutes

Pass out a few pieces of each post it note color and a pen to each member of the team.  For 3 minutes (use a timer), have the team write down memorable events during the iteration with the following criteria:
Green Color -> Item that went well for this iteration
Blue Color -> Item that was confusing
Red Color -> Item that was painful or didn't go well

At the end of the 3 minutes, collect all of the post it notes and organize them into categories on a whiteboard.  The number of categories will vary depending but keep the number of categories no greater than 5 categories.  Once the post it notes are categorized, have each team member vote twice on which categories they would like to discuss.  They can vote twice on the same category or split them.  Once the votes are tallied, discuss the top 2 categories.  Place a 10-15 minute time box for each category for team members to discuss, more in depth, cards they put on the wall, and how to improve the situation.  Don't feel as if you have to draw it out to the maximum time, if a category's discussion has ended, go onto the next category.  If you have time left over from discussion, ask the team if they want to discuss the third most popular category.  Make sure a time box of the remaining time you have left is for the last category as to respect the time.

Generate Insights

Take the cards from the discussed categories and use them for The Soup Experiment.  This will give the team different perspective on the cards written.  It will help clarify whose responsible for what.  If there are a lot of "painful" cards in team control, then this clarifies items that the team needs to work on.  At this point, come up with action items (assign them to an individual, if you assign it to the team, they'll never get done!) as to how the team can improve the situation, or experiments that the team can try for an iteration to try and improve the situation. 

Close the Retrospective

Thank the team for their time and move onto the planning meeting.

Tips/Tricks from my experience:

  • Don't be overwhelmed!  The first few retrospectives will take longer but will become shorter over time.
  • Let this be an avenue where team members can voice their concerns and solutions but refrain from talking exclusively on the negative items.  Talk about what went well and how to maintain that!
  • Action Items:  these are important and will reflect on how effective retrospectives become.  Come up with measurable action items, assign them to a person, and, most importantly, follow up with the status at the next retrospective.  If items are under the team's control, do everything possible to complete those action items sooner rather than later.
  • Limit your action items to between 3 - 5 items, take the highest priority items.  It's easier to remember 3 - 5 items versus 20 plus they are more likely to get done.
  • Switch up your retrospective activities!  This will keep the meetings fresh and not get people into a rut.  Check out the book "Agile Retrospectives Making Good Teams Great"
  • Remember to time box activities as much as possible to respect team member's time.

Tuesday, October 5, 2010

Running Coded UI Tests From CruiseControl.NET

This is that last post of a 4 part series on Coded UI Tests.  We will wrap up our example with how to wire up our Coded UI Tests to CruiseControl.NET (our CI Server).  Here's where we've come:

Part 1:  How to Create a Coded UI Test
Part 2:  Code Organization:  Test Lists, Test Categories, Oh my! – Coded UI Test Organization
Part 3:  Running Coded UI Tests From Command Line

This blog will explain how to run Coded UI Tests from CruiseControl.NET. 

Overview Steps

  1. Create a batch file to call the GUI Tests
  2. CruiseControl.NET Configuration
    1. Install “MSTest Reports” package
    2. Modify the dashboard.config file
    3. Modify the ccnet.config file and add a project
    4. Modify the MSTestReport2008.xsl file
  3. Run the project in CCNET
  4. Tips and Tricks
Create a Batch File to Call the Coded UI Tests

First, create a batch file that will run your Coded UI Tests.  I've blogged about how you can do that here <LINK>.  Note that you if you choose to run multiple tests from one command line prompt, the order in which they are ran is not guaranteed.  I've worked around this by calling 3 commands, in order, with 3 different result files.  If you don't save them to different files, the second command will error out because the file already exists.  Since we have 3 different result files, we'll use CC.NET to merge them all into one report.  Here's our sample bat file:


rd /S /Q "C:\build\reports"
mkdir "C:\build\reports"
cd C:\Build\Working\
"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\mstest.exe" /testmetadata:"C:\Build\Working\CalcCodedUITest.vsmdi" /testlist:List_LoadCalc /resultsfile:"C:\Build\Reports\List_LoadCalcResults.trx"
"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\mstest.exe" /testmetadata:"C:\Build\Working\CalcCodedUITest.vsmdi" /testlist:PerfCalcResults /resultsfile:"C:\Build\Reports\PerfCalcResults.trx"
"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\mstest.exe" /testmetadata:"C:\Build\Working\CalcCodedUITest.vsmdi" /testlist:ShutDownCalcResults /resultsfile:"C:\Build\Reports\ShutDownCalcResults.trx"

The interesting things in this code is we delete the folder the reports are created in (C:\buid\reports) since they are merged in CCNet and we change the directory to the directory of the solution (C:\build\working) and then run 3 seperate test lists.


CruiseControl.NET Configuration

Install the MSTest Reports Package

-Assuming you have CC.NET installed, go into CCNet's Administer Dashboard and install the "MSTest Reports" package.  This package will enable you to view the test results through CC.NET.

Modify the dashboard.config File

In order to view the results, you need to tweak the dashboard.config file (default location: C:\Program Files\CruiseControl.NET\webdashboard) first and change the xsl file from MsTestSummary.xsl to MsTestSummary2008.xsl in the <buildPlugins> tag so it looks like the following:

      <buildLogBuildPlugin />
      <xslReportBuildPlugin description="MSTest Report" actionName="MSTestBuildReport" xslFileName="xsl\MsTestReport2008.xsl"></xslReportBuildPlugin>

Do an IISReset.  IISReset is necessary for CC.NET to pick up the changes.

Modify the CCNet.config file

Next, you'll need to add the project to the ccnet.config file (default location:  C:\Program Files\CruiseControl.NET\server\ccnet.config) that will execute an "exec" task that will call your batch file to run the Coded UI tests.  More examples can be found using CruiseControl.NET documentation

First, add the queue name like so:

<queue name="alpha" />

Then add the project node with a name, etc, like so:

<project queue="alpha" queuePriority="1">
        <name>Coded UI Command Line</name>
            <exec executable="C:\CodedUIFiles\CalcCodedUITests.bat" />

The interesting piece is that we are merging 3 ".trx" files.  We needed to ensure the order in which the test lists are ran and to ensure the order, in the bat file, we have 3 command lines executing tests, one after the other, to different results files.  If we had set it to the same results file, the system will error out stating that the file already exists.  These file names correspond to the file names that are created in the bat file when the tests run and get deleted before every run.  Since the files are merged into the CCNet report file, there's no need to keep them twice.

Modify the MSTestReport2008.xsl File

A side effect to running 3 command line tests is in the reporting, it will only show the same number of tests that are in the last group of tests ran.  In order to sum up all the tests ran, we need to modify the MsTestReport2008.xsl (C:\Program Files\CruiseControl.NET\webdashboard\xsl\MSTestReport2008.xsl).  Modify the file and add the sum commands like so:

    <xsl:variable name="pass_count" select="sum(/cruisecontrol/build/*[local-name()='TestRun']/*[local-name()='ResultSummary']/*[local-name()='Counters']/@passed)"/>
        <xsl:variable name="inconclusive_count" select="sum(/cruisecontrol/build/*[local-name()='TestRun']/*[local-name()='ResultSummary']/*[local-name()='Counters']/@inconclusive)"/>
        <xsl:variable name="failed_count" select="sum(/cruisecontrol/build/*[local-name()='TestRun']/*[local-name()='ResultSummary']/*[local-name()='Counters']/@failed)"/>
        <xsl:variable name="total_count" select="sum(/cruisecontrol/build/*[local-name()='TestRun']/*[local-name()='ResultSummary']/*[local-name()='Counters']/@total)"/>

Save the file and do an IISReset for CCNet to pick up the changes.

Run the Project in CCNET

Go to CCNet and click on "Force" to force the Coded UI tests to run.
Once the tests are finished, click on the name of the project -> "Latest Build" on the left hand side -> "MSTest Report"

Tips and Tricks

Here are some tips and tricks in running Coded UI tests from a WinForms application:

  1. Due to security issues, CCNet cannot run as a service and run Coded UI Tests.  Turn the service off and run the CCNet application as an Administrator.

  2. The Coded UI Tests can be kicked off from any machine that can access the CCNet web page.  However, the computer's desktop that CCNet is installed on will need to be maximized and unlocked (you can operate this from an RDC session) in order to run tests.  If the CCNet computer's desktop is locked, minimized or set to a different screen resolution than when i twas recorded, the tests will fail and throw a "can't interact with desktop" error.

  3. Sometimes you can get a false positive and CCNet will say the last build status will say "Success".  This will not be necessarily the case for all tests.  After the Coded UI tests are ran, make sure you view the MSTest Report to view which tests passed or failed.

  4. Ideally, set up CCNET to pull down the code from your source control, compile it, then run the Coded UI tests from the bat file.

  5. Structure your bat file to run test lists, not individual tests.  The advantage to this is that when new tests are added to the list, you won't need to modify the bat file, it will just be included.  Organizing in test lists also allow for horizontal scalability.  For example, say you have a large application that runs on multiple back ends, you could setup another CI Server on another VM, setup a new bat file just with a specific back end of tests, and let that VM run tests at the same time.

  6. Coded UI Tests are slow by nature so over time you'll want to set up a schedule trigger in CCNet to kick this off at a certain time, for example, as an over night process.  I would also recommend a dedicated computer or VM to perform these tests.

Hope this has helped down your path of automated Coded UI tests. 

Friday, October 1, 2010

How to: Run Coded UI Tests from a Command Line

This blog post is a third in a series on Coded UI tests and have assumed you’ve looked at the previous two posts:

Part 1: Create a Simple Visual Studio 2010 Coded UI Test

Part 2: Coded UI Tests: Test Lists, Test Categories, Oh my!

Now that we have a test suite and we have organized our tests, how can we run them from a command line? Once we have tests running from a command line, we can then wire it up to a continuous integration (CI) server like Cruise Control.Net (which will be a later post) and have them to run automatically.

Running a Coded UI Tests from Command Line Based on a Test List

1. Open up with Visual Studio 2010 Command Prompt Window (Start->Programs->Microsoft Visual Studio 2010->Visual Studio Tools->Visual Studio Command Prompt (2010))

2. Point to the directory of your Solution file. In our case it will be C:\Projects\GUIPOC

3. Enter the following command prompt to run all tests
Mstest /testmetadata:CalcCodedUITest.vsmdi /testlist:LoadCalcTestList

4. The test list will load and execute like the following:

Other popular MSTest commands to run tests:

These examples are based that steps 1 and 2 were followed above.

Run Test by Test Name
  • Mstest /testcontainer:CalcCodedUITest\bin\debug\CalcCodedUITest.dll /test:LoadCalculator /unique
Run Test by Category
  • Mstest /testcontainer:CalcCodedUITest\bin\debug\CalcCodedUITest.dll /category:CalcCategory
Run Test by Category and Publish Results to a Declare File
  • Mstest /testcontainer:CalcCodedUITest\bin\debug\CalcCodedUITest.dll /category:CalcCategory /resultsfile:”C:\LogFile.trx”
Tips and Tricks
  • The “.vsmdi” file stores the links to other tests. This is associated with the solution so you have the ability to store tests from multiple projects in the same solution under one test list.
  • If you declare multiple tests to run in one command line, the order in which they run are not guaranteed. If you need to ensure the order, ensure it using the command line by having multiple command lines executing tests.
  • If a results file already exists, another test run using the same results file name will error out and complain that that file already exists.
Additional Resources:

Thursday, September 30, 2010

Coded UI Tests: Test Lists, Test Categories, Oh My!

This is part 2 of a series of blog posts covering Coded UI Tests. This post will assume you’ve read part 1: how to create a coded ui test.

As a test suite is getting built, organization is very important. It’s very important in order to I’ll show you two different ways to organize Coded UI Tests, through test lists and test categories. There’s an xml file that stores the mapping of test lists to tests in a .vsmdi file that’s associated with your solution. This allows us to create test lists that cross projects or even within the same project.

Organizing your tests offers many benefits including easier to locate the test in addition to helping with running Coded UI tests from the command line (which I’ll discuss in a later post).

Test Lists:

One test method can belong to multiple test lists. You can also create a hierarchy test list structure, test lists inside of a test list. Test methods can be run by calling the test list, however, the order in which the test methods execute in the test list are not guaranteed to be in any certain order.

How to create a new test list:

1. Load a Coded UI Solution

2. Open up the “.vsmdi” file in the solution.

3. This will open the “Test List Editor” window

4. Right Click on the “Lists of Tests” and create a new test list. We’ve named this “LoadCalcTestList” and click “OK”

5. This will add it under your “Lists of tests” like so.

6. In order to add a test to a test list, open up the Test View Window (Test->Windows->Test View)

7. Click and drag the “LoadCalculator” test into the “LoadCalcTestList” tree item in the Test List Editor like so.

Test Categories

One test method can belong to one or multiple test categories. Just like test lists, you can run a category of tests but the order in which test methods are executed are not guaranteed.

These test categories are effectively attributes above the test method. Programmatically, a test category looks like the following code snippet:

[TestCategory("CalcCategory"), TestMethod]
public void LoadCalculator()

This will show the GUI way on adding Test Categories:

1. In order to add a test to a test category, open up the Test View Window (Test->Windows->Test View) and highlight the test.

2. In the properties section, there’s a “Test Categories” property. Click on “…” eclipse button. This will load the following window and input the following information:

3. Click “Add” and it will put the “CalcCategory” into the “Assigned Categories” list and click “OK”.

Download Sample Coded UI Solution

Monday, September 27, 2010

Create a Simple Visual Studio 2010 Coded UI Test

In this blog, I’ll explain how to get up and running quickly on Coded UI Tests. This walk through will record a test that opens the “Calculator” program that comes with Windows.

The Coded UI Test functionality is available in Visual Studio 2010 Premium or Visual Studio 2010 Ultimate.

1. Open Visual Studio 2010

2. Go to File->New->Project

3. Create a new “Test Project” in Visual Studio 2010. I’ve named this one “CalcCodedUITest” under “C:\Projects”.

4. Click “OK”.

5. This will create the “Test Project” project with the following file structure:

6. Delete the UnitTest1.cs file and add a Coded UI Test by right clicking on the Project Name -> Add -> New Test and name the new test as “CalcTests.cs”

7. Click the “Cancel” button on the following screen:

8. Rename the “CodedUITestMethod1()” method to “LoadCalculator()”

9. Place the cursor in the “LoadCalculator” method and right click and select “Generate Code for Coded UI Test -> Use Coded UI Test Builder”

10. Click the record button to record the test

11. Type Windows Key + R

12. Type “Calc”

13. Click “OK”

14. Click the “Pause” button to pause the test

15. Click the “Show Record Steps” button to review the steps that it has recorded.

16. Your steps should look like the following:

17. Click the “Generate Code” button

18. Name your method. In this example, I named it “LoadCalc”

19. Click “Add and Generate” button

20. Now the “LoadCalculator” method is now populated with the “this.UIMap.LoadCalc();” statement.

21. Run the test by placing the cursor in the function, right click in the method and click “Run Tests”

22. If all worked correctly, the system would have loaded the “Calculator” application!

23. Congrats on creating and running your first GUI test!

Download Sample Coded UI Solution

Tuesday, September 21, 2010

Enter the Matrix: The Knowledge Matrix

How do we determine which person is on what team and identify learning opportunities between team members?  Here’s where we enter the matrix, the Knowledge Matrix.  This technique clarifies a team member’s skill set and opportunities for pairing with other team members to bleed knowledge.


  1. Snapshot to target each person’s skill set Tool to bring skill sets together.
  2. Clarifies learning opportunities between different skill set levels
  3. Great example of a big visible chart that Agile preaches.  We can extend this idea into charts and graphs to graphically display the data.  This data can be compiled into radar charts comparing individuals and/or teams.

How to:

  1. Create a spreadsheet that looks like the following:


  2. List out areas that are important to you.
    1. Domain Specific Knowledge – specific knowledge about the environment the system targets.  This is often learned by interacting with users of the system.
    2. Technical Knowledge – what tools and/or language(s) your shop is using that is important to the project
  3. Have other team members rank an individual for each skill set.  Alternatively, have individuals rank themselves given the following criteria (Dreyfus model as was explained in and excerpt from Pragmatic Thinking and Learning: Refactor Your Wetware) :
    1. Novice – beginner in a subject area.  They need “recipes” in order to accomplish a given task.
    2. Advanced Beginner – try tasks on their own but have difficulty troubleshooting. “Advanced Beginners don’t want the big picture.”
    3. Competent – can troubleshoot.
    4. Proficient – individuals who need the big picture, they have the ability to self-correct and learn from others.
    5. Expert – primary source of knowledge and information in a subject area.  Explore better, different ways to perform a task. “Experts work from intuition”.
  4. Post the results for all to see

We’ve learned from this tool in effectively setting up teams.  In our trivial example, Joe and Jane would be a great pair.  They have roughly the same amount of Domain Knowledge but Joe could teach Jane T-SQL and Jane can improve Joe’s C# knowledge. Each member can benefit from the other’s experience.  Re-assess this spreadsheet periodically to clarify learning opportunities to keep your team sharp in both domain knowledge and technical knowledge.

Other Resources

  1. Pragmatic Thinking and Learning: Refactor Your Wetware – great book on learning and the process to get from Novice to Expert.
  2. Building Software Development Expertise – Using The Dreyfus Model
  3. Five Stages of Learning – provides an overview of each stage and gives suggested time benchmarks.


“None of us is not as smart as all of us.” ~ Ken Blanchard

Wednesday, September 15, 2010

Getting the User’s Current Context in SQL

I had the need to get the context of the currently logged in user for SQL.  So I thought I’d share:

SELECT system_user as CurrentUser
    ,db_name() AS CurrentDatabaseName
    ,CurrentDefaultSchema = (SELECT default_schema_name from sys.database.principals where name = user_name())

Column Name Definition
CurrentUser The username of the currently logged in user.
CurrentDatabaseName The current database the user is pointed to.
CurrentDefaultSchema The schema this user is associated with.  Note that if the user has “sysadmin” role, the schema role will be “dbo”.

Hope this helps.

Wednesday, September 8, 2010

“The Soup” Experiment

Teams often have difficulty determining the source of issues and focusing on who’s responsible for correcting those issues raised in a retrospective.
Teams often focus on items that are not under their control.  In an effort to help our teams stay focused we ask the following questions:
  • How can we make our team better?
  • What are our team’s strengths and weaknesses?
  • What specific action items can we work on to make our team better?
We experimented with the Circles and Soup collaboration technique.  This technique clarifies who’s responsible for the items.  On a board, draw three circles, like a bulls eye:

1. Team Control – represents items that are specifically under your team’s control.
Examples can include:
  • Our team needs 85% code coverage in testing.
  • Our team needs to do more pair programming
  • Our team needs to switch programming pairs.
2.  Team Influences – represents items that the team can influence but not take total ownership of.  These are items that will typically affect other teams that you can influence or make suggestions on but are unable to directly change them.
Examples include:
  • Continuous Integration configurations that would affect other teams
  • Changing source control software
  • A new tool
3.  “The Soup” – represents items that are suggestions.  These are typically items that you can suggest but have no real influence over.
Examples Include:
  • Setting an acceptable company bug rate
  • Influence with another department
  • Direction of the product.
Here’s an example of what the layout looks like:

Our experience was that for the first few iterations, most of the pain points we identified were classified as “Team Controlled”.  The team was able to identify and execute action items to improve these team controlled pain points.  We repeated the Circles and Soup exercise for each iteration and after 4 weekly iterations, the pain points went from “team controlled” to all the pain points being outside of the team’s control, the only cards that were in team controlled were good points!
I’d says that the team was focused on problems they couldn’t fix, and that frustrated them.  Once they began to realize which problems were with the organization instead of the dev shop, and the dev shop instead of their team, they understood which problems they could solve, which they could affect, and which they could (sometimes) influence.
This is a great way to help your team focus on problems they can actually solve.

Wednesday, September 1, 2010

Here I go...

I've finally done it, I've got a blog!

I'm a .NET Software Developer working in the Agile space.  My goal with this blog is to post things I'm currently working on, hoping to contribute my experiences in hope they will help out someone else.

“Think of me as a fellow patient in the same hospital who, having been admitted a little earlier could give some advice.” -C.S. Lewis