Marcelo E Silva

Integrating Selenium tests in a release pipeline in VSTS and TFS 2018

Marcelo E Silva — Wed, 07 Mar 2018 14:49:28 GMT

Today, I'd like to show you a proof-of-concept I created for one of my customers where we implement User Interface (UI) test automation into a Continuous Integration/Continuous Delivery (CI/CD) pipeline in Visual Studio Team Services (VSTS). First, a little background on the problem we're trying to solve: my customer wanted to introduce automated testing into their CI/CD pipeline. The conversation when in the direction of integrating Unit Tests and doing automated Integration Tests. We did implement some unit tests and integrated them into the solution and the release pipeline. However, there are clear challenges on implementing unit tests on legacy code. Can you justify the time/effort to implement a good set of unit tests on legacy code? I'm not going to go deep into this topic, which is worth a blog post on its own. Suffice to say that, most teams choose to do a gradual implementation of unit tests as bugs are fixed and technical debt is paid. Some teams find it easier to start implementing UI "smoke tests", in parallel with the effort of gradually implementing unit tests. In this example, we cover the scenario where we have automated deployments, but the developers perform smoke tests to make sure the application was successfully deployed. These tests can be simple, like: going to the home page of a web app, clicking on a link that requires database connectivity, running a report, etc. I'll be using the famously old TailSpin Toys web app for this. It's a simple web app where you can buy paper planes. The idea is that we want to run a couple of smoke tests:

Browse one of the products and make sure the data retrieved from the database is correct
Add a product to the shopping cart, fill out the order and make sure the total is greater than zero

First, what we do is we create a Unit Test project in Visual Studio, adding the following Nuget packages. I'm using MSTest framework, but you can use any other framework of your choice: Note that, you only need the PhantomJS packages and Selenium.WebDriver. The other ones are there so I (or you) can execute the tests in a Chrome, IE or Firefox window and see it executing for debugging/test purposes. Next, jumping into our C# class that hosts the tests, we have the following: This method runs once the before all the tests in this C# class run and, in this case, I chose to use it to initialize the test URL to be used and to initialize the PhantomJSDriver. Next, we go to the TestInitialize method, where it runs before every single test in this class: Here, before every test, we make sure the ImplicitWait is reset to 30 seconds and that we navigate back to the home page. If you want to run the test in a virtual maximized window, you can do that by using the Window.Maximize() method seen above. This might come in handy if you have a web page that doesn't fit well in a small window, or better yet, you want to test your responsive design and then can set the window size to an iPad Mini for example: _driver.Manage().Window.Size = new System.Drawing.Size(1024, 768); The first test method is the Browse scenario where we test for the data in the description field: Let's dissect this test method:

TestCategory attribute: I set this as to differentiate the smoke tests from other types of tests in the same project. I can then tell VSTS to only run tests with this category during a release, not during a build. You can also use different projects.
The test consists, basically of finding the element (anchor in this case) where id=model and click on it. Then we click on the first product in the list, extract its description and check whether it's a non-null string with length > 0.
I have used XPath to find the elements, but you can also find elements by ID, tags, etc.
I have added steps to take screenshots before each step. One takes the screenshot and saves it as a JPG file while the other adds it to the results file. The latter is an important step as it will allow you to see the screenshots in the Test hub in VSTS

Here's the other method where we add a product to cart, fill out the order form and check the total price is > 0:

This one has a good set of examples on how to find elements using different methods
Notice that it now becomes important for you to make the web app "testable" by making it easy for someone writing UI tests to find and identify the elements in the DOM.

If you have Chrome, you can use one option for finding out what the XPath is for a giving element, by inspecting it and copying the XPath to the clipboard: Now, when this is checked in to my project in VSTS, it kicks off a build. In that build, I make sure that no smoke tests are executed: Now, on my release definition that's used to deploy the application, I have two environments: QA and Prod: In this example, I chose to run the smoke tests in the QA environment after deployment, and in Prod after deployment targeting the staging slot. Once the tests pass in staging, there's a manual approval step where we proceed to swap slots and make the deployment official. Note that, when the smoke tests are executed, we make sure we only run them, not any other Unit tests by selecting the proper category: QA process: Production process: Once we trigger the release for QA, it runs successfully, and we can see the test results: And we can see screenshots of the smoke tests as well. The sequence below is the add to cart test: There you have it. Now, as a follow-up to this, I'm planning on showing how to do a similar case for a Win32 app test on Windows 10 using an Azure VM as test bed. This will include installing and using Appium.

Using web.config transforms and Release Manager - TFS 2017/Team Services edition

Marcelo E Silva — Thu, 09 Feb 2017 21:37:08 GMT

This is a follow-up to an old post on Using Web.Config transforms and Release Manager that I did some time ago. That post was done on TFS 2015 and using the now "old" architecture of Release Management. This post will follow the same idea of deploying an application to Azure (App Service), but this time using Visual Studio Team Services and its Build/Release system. This can be easily translated to TFS 2017 RTM, the latest TFS version at the time of this writing. I'll be using an old MVC app (TailspinToys) as an example and will be focusing on the web.config changes only. I'll check if I can post the source code for this later, but this is an old app that I used to expedite the work on writing this, so you might want to use a newer framework. First, from a developers perspective, I want to make sure my app runs on my laptop and uses my LocalDB as database server. This way, I can have a full test bed for my work before I deploy it to Azure. My web.config, by default, points to my LocalDB: The debug transform doesn't need any changes: Running the application locally, you should get: [caption id="attachment_115" align="alignnone" width="1024"] TailspinToys running locally on developer's machine[/caption] If you don't have the infrastructure setup on Azure yet, this is a good time to do it. I won't go into too much detail on how to create a web app and Azure SQL database, but there is good documentation on the web on how to do it. In this example, I'll create two web app/sql pairs: one for QA, another for Prod. In prod, we'll have two slots, just for fun. [caption id="attachment_125" align="alignnone" width="1024"] Azure environments[/caption] We can now create a web.config transform to "tokenize" the connection string. This token will then be replaced at deployment time. In the example below, we created in Visual Studio a configuration called "Azure" and created the corresponding transform (by right-clicking on the web.config and selecting "add web config transform"): [caption id="attachment_155" align="alignnone" width="1024"] Web config for Azure with tokenized connection string[/caption] Notice that I used "__" as token delimiter. It's not a requirement anymore, but I kept the same syntax used in the previous Release Management versions. Code is committed and pushed to VSTS. Now we have to setup a build for the QA environment: [caption id="attachment_165" align="alignnone" width="1024"] Build variables specifying "Azure" configuration to build[/caption] [caption id="attachment_185" align="alignnone" width="1024"] Repository setting to pull code from a specific branch[/caption] Notice that I also used some MSBuild arguments to make sure we get the properly packaged output. In this case I used /p:DeployOnBuild=True In the copy artifacts steps, I specify all the files I need for deployment:

**\Package\*.zip
**\Package\*.cmd
**\Package\*.xml
**\output\*.dacpac

[caption id="attachment_325" align="alignnone" width="1024"] Artifacts to be published[/caption] Once the build is successfully executed, we can see the artifacts published and ready to be used: [caption id="attachment_315" align="alignnone" width="1024"] Build artifacts created after successful build[/caption] Let's download the folder "Package" with all the web deploy files and examine the SetParameters file: [caption id="attachment_335" align="alignnone" width="1024"] Parameters.xml file[/caption] Notice that our tokenized connection string is created for us here. If you'd like to add more parameters, even if not in web.config take a look at this article. Next step is for us to create a release definition that deploys the web app and database to the QA and Production environments we created earlier. The definition will replace the tokenized config set in the parameters with the correct connection string to the corresponding database. The steps to deploy to QA should be: A couple of points here:

I used one of the replace token tasks available on the VSTS marketplace. You can use any other, just make sure you know how to configure them to identify the tokens
Notice that I specify the token delimiters as "__". In this task you can use anything. I kept the "old" setup to make it simple.
I specify the parameters file directly (full path) but you don't have to. Same for the package zip

The variables are set at QA environment level. Notice the variable with the same name as the token, without the "__": The production environment will be very similar, but this time we want to accomplish a couple more things:

Deploy only if QA is successful
Deploy to staging slot first then wait for manual confirmation
Swap staging and prod slots for final deployment

The production deployment steps will then look something like this: Notice:

Variables are the same as in QA, but with production values (server names, etc)
Manual intervention step is created. Here you should consider whether you really need manual intervention or even better: automate smoke tests to run against the staging environment and proceed with slot swap only if those tests pass
There's no swap for the prod DB, which is deployed regardless. It may be better to consider creating a staging DB to be used or use a refactoring pattern for DB changes that allows for deployments that don't break the existing application running in production
The swap slot step has an inline PowerShell script. You can choose to check that in as code and have a task call that script instead.

Running the release we get the app deployed and running in the QA environment: If we go to the Kudu console for the web app in QA, we see that our web.config transformation happened without issues: Now, in production is the same pattern. The only difference is that the app is deployed first to the staging slot. Running in staging slot: But not yet in production slot: Once the deployment happens to staging, approval is needed for the manual intervention: Then the slot is switched and the app is now running in production: We can also verify that the web.config correctly points to the production database in Kudu: There you have it. Now on to another post soon.

Using web.config transformations and Release Manager

Marcelo E Silva — Mon, 19 Jan 2015 11:16:00 GMT

UPDATE: Look for a newer version of this post that uses the new TFS 2017/Visual Studio Team Services new architecture. First: yes, it's been a long time since I published anything. It's been a busy year and finding time to blog was really tough. For the commenters on my previous posts: apologies for not being prompt on replies. Anyway, one of my 2015 resolutions is to do better at blogging. :-) The idea behind this post is to show what I've done on 2 of my clients where we implemented build automation and Release Manager, getting a proof-of-concept application to successfully deploy to environments and to properly manage web.config transformations leveraging Release Manager.

Scenario

I'm going to use a dummy MVC Web Application that's basically the Visual Studio 2013 template plus a small modification to the web.config so that we can demo the workflow. The example I have is to show a message on the home page from a setting in the web.config. This setting then varies based on the environment (dev, prod, etc) the application is running on, and this will be the variable that will be changed by web.config transformations and Release Manager. Although I'm using an AppSettings key, you can use it for other settings and connection strings as well. The same rules apply. I made the following modifications: Index.cshtml HomeController.cs Web.config The application should show the msg from the web.config settings as per below (running from Visual Studio);

Setting up web.config transforms

I'll not go into too much detail on how to setup web.config transforms and what the transformation syntax is for them, as they've been very well explained on MSDN. The strategy that I used here was to structure my transformations so that:

The original web.config file has the settings needed for the developer to run in debug mode in Visual Studio
I added a new configuration (Release) that will have the proper web.config transformations to put tokens in the key/values that I need to be changed later by Release Management:

The same transformed config using Release configuration will be used by Release Management (RM) to deploy to all the environments in the release path.RM will then substitute the "__EnvLabel__" token with the appropriate value for each target deployment environment.

TFS Build

You can use any template for the build, including the RM template to trigger a release directly from the build. The trick here is to force the web config transformation to happen during build, so you end up with a web.config that has the tokens RM is expecting. By default, web config transformations only happen during deployment. In order for you to add this behaviour, you can add the following arguments to MSBuild:

/p:UseWPP_CopyWebApplication=true /p:PipelineDependsOnBuild=false

Also, make sure that you're building the correct configuration that has the transforms to add the token (in our example is Any CPU and Release): Once the build finishes, the output should look like this (noticed the web.config transformed to include the token):

Release Path setup

Now, we have to take that config and replace the tokens with the proper values according to the target environment. In this example, I'm going to use an Agent-based setup. I'll update this later to also include an Agent-less deployment using PowerShell Desired State Configuration (DSC). First we configure Release Manager Server, Release Management Client and a deployment agent on the target server. You can find more detailed information on setting up those parts here: Install Release Management Server and Client, Install Deployment Agents.. I used the same target server to simulate both DEV and PROD IIS environments, by using two different ports: Then I configured a server in RM to point to that box: Next I configured the two environments, DEV and PROD: Next step is to configure a release path where we have a DEV -> PROD deployment flow: The setup above is, of course, overly simplistic for demo purposes. What you should have in mind is that you can configure who can approve (individuals or groups), who can validate and whether those steps are automated or not. In my example, I don't need approvals for DEV, but need one for PROD. When the deployment workflow is initiated, DEV will be deployed automatically while PROD will wait for an approval before proceeding. Next step is to configure the components to be deployed, in this case our web application: I chose to use the "builds with application" option, since I'm going to use the build definition that will be defined in the release path. Next, I'll setup the deployment tool. In my case, XCopy, but you can use MS Deploy or other tool as appropriate: The secret of the web.config token replacement happens here on the Configuration Variables. We specify that the replacement happens "Before Installation", so that the config file is updated before being copied to the target server. We also specify the wildcard to tell RM what files we want RM to look for tokens: in this case *.config. Next we define the release template. In this example:

You can see the DEV -> PROD workflow
Servers in the deployment (I only have one in this example, but you might have multiple most likely)
Components: the application being deployed (you might have to manually add it by right-clicking Components
I included optional steps to backup current site, and to rollback in case deployment fails (more of a best practice, but they're not necessary)

Notice that the "EnvLabel" token we specified before gets a value here, depending on the environment, along with the other variables like target and backup folders:

Deploying

Let's get some action going! We initiate the release manually, choosing the template we configured previously, PROD as the last stage and selecting the last build as the one to deploy: After a while we should see the following results: Notice that the deployment to DEV was completed, but deployment to PROD is waiting for approval. DEV has been successfully deployed: While PROD has not yet: The reason is that we're waiting for approval. Let's go ahead and open the approval window using the RM web client: Clicking on the "Approve" for the selected release, we get the following dialog: If we want to approve, but delay the deployment for later (off-hours deployment), we can click on the "Deferred Deployment" and select a day/time for when the deployment will execute: After approval is given, the workflow resumes and finishes deploying to PROD: There you have it!

Finding Event Subscriptions in TFS 2012 Using PowerShell

Marcelo E Silva — Sun, 05 May 2013 19:00:00 GMT

Update: Changed script to use System.Collections.ArrayList for increased performance

Update: You can use the ArrayList but a better approach is to not use it and just pipeline each object out, so I updated the script to reflect that

Well, I'm going thru some PowerShell training at the moment and thought I could continue to apply that into my ALM needs. In this case, I came across a client that had several warning messages about the notification event failing for some email deliveries. This was detected on the Best Practices Analyzer tool found on Team Foundation Power Tools for 2012.

Their TFS setup is fairly large and contains several team projects with around 250 users, with some degree of turnover. I needed some way to list all subscriptions in the system in a format they could then query.

The script below will create a function that will connect to a TFS collection and then list all existing subscriptions. The subscriptions will be listed in an array of PSObjects, that can be piped into a Where-Object for additional filtering. The created object is a "flatter" version of the original object and it's easier to query. In addition to that, I added some code to resolve the identity of the subscriber.

I also added code that, instead of using a custom PSObject, it uses the original .Net and I add the subscriber identity as an extended property. Either way works, so you can pick which one you like best.

Once you find the subscriptions that are invalid, you can delete them using the BISSUBSCRIBE.EXE tool and passing the subscription id.

The PowerShell script will create the following output (this example uses the collectionurl parameter, but if you don't specify it a dialog will pop up for you to select the collection):

Here's the script:

#TFS Powershell function to list all event subscriptions in TFS

#for all team projects (or a specific team project) in a given collection

#Author: Marcelo Silva (marcelo.silva@microsoft.com)

function Get-TFSEventSubscriptions

{

Param([string] $CollectionUrlParam,

[string[]] $Projects)

# load the required dlls

# Below is correct syntax for v3

Add-Type -AssemblyName "Microsoft.TeamFoundation.Client, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

#This syntax is deprecated, however it loads whatever version you have of Team Explorer, :-)

#[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Client")

$tfs

if ($CollectionUrlParam)

{

#if collection is passed then get tfs collection obj

$tfs = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($CollectionUrlParam)

}

else

{

#if no collection specified, open project picker to select it via gui

$picker = New-Object Microsoft.TeamFoundation.Client.TeamProjectPicker([Microsoft.TeamFoundation.Client.TeamProjectPickerMode]::NoProject, $false)

$dialogResult = $picker.ShowDialog()

if ($dialogResult -ne "OK")

{

exit

}

$tfs = $picker.SelectedTeamProjectCollection

}

# Authenticate current user

try

{

$tfs.EnsureAuthenticated()

}

catch

{

Write-Error "Error occurred trying to connect to project collection: $_ "

exit 1

}

#TFS Services to be used

$eventService = $tfs.GetService("Microsoft.TeamFoundation.Framework.Client.IEventService")

$identityService = $tfs.GetService("Microsoft.TeamFoundation.Framework.Client.IIdentityManagementService")

foreach ($sub in $eventService.GetAllEventSubscriptions())

{

#First resolve the subscriber ID

$tfsId = $identityService.ReadIdentity([Microsoft.TeamFoundation.Framework.Common.IdentitySearchFactor]::Identifier,

$sub.Subscriber,

[Microsoft.TeamFoundation.Framework.Common.MembershipQuery]::None,

[Microsoft.TeamFoundation.Framework.Common.ReadIdentityOptions]::None )

if ($tfsId.UniqueName)

{

$subscriberId = $tfsId.UniqueName

}

else

{

$subscriberId = $tfsId.DisplayName

}

#then create custom PSObject

$subPSObj = New-Object PSObject -Property @{

ID = $sub.ID

Device = $sub.Device

Condition = $sub.ConditionString

EventType = $sub.EventType

Address = $sub.DeliveryPreference.Address

Schedule = $sub.DeliveryPreference.Schedule

DeliveryType = $sub.DeliveryPreference.Type

SubscriberName = $subscriberId

Tag = $sub.Tag

}

#Send object to the pipeline. You could store it on an Arraylist, but that just

#consumes more memory

$subPSObj

##This is another variation where we just add a property to the existing Subscription object

##this might be desirable since it will keep the other members

#Add-Member -InputObject $sub -NotePropertyName SubscriberName -NotePropertyValue $subscriberId

}

Using PowerShell and TFS API to list users in TFS 2010 (and 2012)

Marcelo E Silva — Thu, 07 Mar 2013 13:54:00 GMT

Update: Just wanted to let everyone know that this PowerShell script also runs under PowerShell 3.0 and it also works with TFS 2012 Team Explorer.

Update 2: After some training in Powershell, I updated the script below to also be in the form of an advanced function, taking optional parameters and also using TeamProjectPicker in case no parameters are passed. Enjoy!

First and foremost: this is my first post! :-)

Now, let's get down to business. I've been studying PowerShell for a short time and wanted to practice it and I have recently had a lot of requests from clients where they ask me the easiest way to get a "dump" of all the users on all projects in TFS.

When, why not use this as a good example to learn PowerShell and solve this problem?

Let's begin.

You can get a list of all users by using tfssecurity utility. For example: running

tfssecurity /imx "Project Collection Valid Users" /collection: will get you something like this:

Which is helpful somewhat, but not quite, since it doesn't group users by group membership.

Brian Harry posted in his blog a good solution to this problem using C#. The output of that code is something similar like this:

This is close to what we want, but the listing is not organized in a hierarchical fashion. Yes, you could fix the code to do it, but we're talking about using PowerShell here. :-)

Anyway, the script in this blog post will not require IT admins to have Visual Studio to compile code or rely on a developer to do it for them. It only requires PowerShell 2.0 (also works with 3.0) and Team Explorer 2012 (also works with 2010 SP1)

The script source code is:

#TFS Powershell script to dump users by groups

#for all team projects (or a specific team project) in a given collection

#Author: Marcelo Silva (marcelo.silva@microsoft.com)

function Get-TFSGroupMembership

{

Param([string] $CollectionUrlParam,

[string[]] $Projects,

[switch] $ShowEmptyGroups)

$identation = 0

$max_call_depth = 30

function write-idented([string]$text)

{

Write-Output $text.PadLeft($text.Length + (6 * $identation))

}

function list_identities ($queryOption,

$tfsIdentity,

$readIdentityOptions

)

{

$identities = $idService.ReadIdentities($tfsIdentity, $queryOption, $readIdentityOptions)

$identation++

foreach($id in $identities)

{

if ($id.IsContainer)

{

if ($id.Members.Count -gt 0)

{

if ($identation -lt $max_call_depth) #Safe number for max call depth

{

write-idented "Group: ", $id.DisplayName

list_identities $queryOption $id.Members $readIdentityOptions

}

else

{

Write-Output "Maximum call depth reached. Moving on to next group or project..."

}

else

{

if ($ShowEmptyGroups)

{

write-idented "Group: ", $id.DisplayName

$identation++;

write-idented "-- No users --"

$identation--;

}

else

{

if ($id.UniqueName) {

write-idented "Member user: ", $id.UniqueName

}

else {

write-idented "Member user: ", $id.DisplayName

}

$identation--

}

# load the required dlls

Add-Type -AssemblyName "Microsoft.TeamFoundation.Client, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a",

"Microsoft.TeamFoundation.Common, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a",

"Microsoft.TeamFoundation, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

#[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Client")

#[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Common")

#[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation")

$tfs

$projectList = @()

if ($CollectionUrlParam)

{

#if collection is passed then use it and select all projects

$tfs = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($CollectionUrlParam)

$cssService = $tfs.GetService("Microsoft.TeamFoundation.Server.ICommonStructureService3")

if ($Projects)

{

#validate project names

foreach ($p in $Projects)

{

try

{

$projectList += $cssService.GetProjectFromName($p)

}

catch

{

Write-Error "Invalid project name: $p"

exit

}

else

{

$projectList = $cssService.ListAllProjects()

}

else

{

#if no collection specified, open project picker to select it via gui

$picker = New-Object Microsoft.TeamFoundation.Client.TeamProjectPicker([Microsoft.TeamFoundation.Client.TeamProjectPickerMode]::MultiProject, $false)

$dialogResult = $picker.ShowDialog()

if ($dialogResult -ne "OK")

{

exit

}

$tfs = $picker.SelectedTeamProjectCollection

$projectList = $picker.SelectedProjects

}

try

{

$tfs.EnsureAuthenticated()

}

catch

{

Write-Error "Error occurred trying to connect to project collection: $_ "

exit 1

}

$idService = $tfs.GetService("Microsoft.TeamFoundation.Framework.Client.IIdentityManagementService")

Write-Output ""

Write-Output "Team project collection: " $CollectionUrlParam

Write-Output ""

Write-Output "Membership information: "

$identation++

foreach($teamProject in $projectList)

{

Write-Output ""

write-idented "Team project: ",$teamProject.Name

foreach($group in $idService.ListApplicationGroups($teamProject.Name,

[Microsoft.TeamFoundation.Framework.Common.ReadIdentityOptions]::TrueSid))

{

list_identities ([Microsoft.TeamFoundation.Framework.Common.MembershipQuery]::Direct) $group.Descriptor ([Microsoft.TeamFoundation.Framework.Common.ReadIdentityOptions]::TrueSid)

}

$identation = 1

Write-Output ""

Write-Output "Users that have access to this collection but do not belong to any group:"

Write-Output ""

$validUsersGroup = $idService.ReadIdentities([Microsoft.TeamFoundation.Framework.Common.IdentitySearchFactor]::AccountName,

"Project Collection Valid Users",

[Microsoft.TeamFoundation.Framework.Common.MembershipQuery]::Expanded,

[Microsoft.TeamFoundation.Framework.Common.ReadIdentityOptions]::TrueSid)

foreach($member in $validUsersGroup[0][0].Members)

{

$user = $idService.ReadIdentity($member,

[Microsoft.TeamFoundation.Framework.Common.MembershipQuery]::Expanded,

[Microsoft.TeamFoundation.Framework.Common.ReadIdentityOptions]::TrueSid)

if ($user.MemberOf.Count -eq 1 -and -not $user.IsContainer)

{

if ($user.UniqueName) {

write-idented "User: ", $user.UniqueName

}

else {

write-idented "User: ", $user.DisplayName

}

There are a couple of points to note about this script:

The script uses recursion to navigate a tree of group memberships. In my tests, I found that I had to specify a max # of recursions in order to avoid a call depth error in PowerShell.
The ShowEmptyGroups option can be used to list all groups, even ones that are empty
You can pass an array of team project names if you want, otherwise it will list all team projects in the given collection
If you don't pass a team collection URL, it will pop up a dialog so you can select the team project collection and the team projects you want the report for.
There is a "bonus" piece of code at the end that lists anyone that have permissions set at individual level without belonging to any groups.

You should get an output similar to the one below:

PS C:\Users\marcelos\Documents\TFS PowerShell> . .\TFS-Dump-Group-Membership.ps1

PS C:\Users\marcelos\Documents\TFS PowerShell> Get-TFSGroupMembership https://192.168.1.72:8080/tfs/defaultcollection -ShowEmptyGroups

Team project collection:

https://192.168.1.72:8080/tfs/defaultcollection

Membership information:

Team project: JobsSite

Group: [JobsSite]\Project Administrators

Member user: TFS10RTM\TFSSETUP

Group: [JobsSite]\Contributors

Member user: TFS10RTM\Darren

Member user: TFS10RTM\Nicole

Group: [JobsSite]\Readers

Member user: TFS10RTM\Larry

Group: [JobsSite]\Builders

-- No users --

Team project: TailspinToys

Group: [TailspinToys]\Builders

-- No users --

Group: [TailspinToys]\Readers

-- No users --

Group: [TailspinToys]\Project Administrators

Member user: TFS10RTM\Andrew

Member user: TFS10RTM\TFSSETUP

Group: [TailspinToys]\Contributors

Member user: TFS10RTM\Darren

Member user: TFS10RTM\Larry

Team project: MyApplication

Group: [MyApplication]\Project Administrators

Member user: TFS10RTM\TFSSETUP

Group: [MyApplication]\Contributors

Group: [MyApplication]\DatabaseDevelopers

Member user: TFS10RTM\Andrew

Member user: TFS10RTM\Darren

Group: [MyApplication]\Readers

-- No users --

Group: [MyApplication]\Builders

-- No users --

Group: [MyApplication]\DatabaseDevelopers

Member user: TFS10RTM\Andrew

Member user: TFS10RTM\Darren

Users that have access to this collection but do not belong to any group:

User: TFS10RTM\Renee

PS C:\Users\marcelos\Documents\TFS PowerShell>

There you have it!