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.UIMap.LoadCalc();
}

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.

Advantages:

  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:

    image

  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:
circles-of-c-i-soup-blank-small

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