Just like design patterns, the use of test patterns will make your life easier. A lot of the common testing methods can be reused. Along with the benefits of reuse, using patterns makes it easier to explain to others what you are going to do in a word or a two instead of telling the whole story. Moreover, test patterns provide guidelines for solving common test design problems and define measurable actionable methods of testing. Test patterns have certain attributes that shape the pattern. It has an easy to remember name, which people agree upon and use to refer to the same test method. The pattern should be used to solve a certain problem, the same problem can be addressed by multiple problems, however, a pattern should tackle one problem and focus on its solution. Analysis of the problem addressed by the pattern is very important as it shows the various dimensions of the problem and why this pattern is the best solution for it. Test patterns are basically design patterns to solve testing problems; it has to have an algorithm or a sequence that forms the solution and shows how the test cases will be implemented. When test cases following this pattern are run, they will yield results that should be expected by the oracle of the pattern. And to make it easier for others who are going to use the pattern, it should list some examples, and how it relates to other patterns; a pattern doesn’t have to have related patterns though. To be explicit about when the pattern should be used and when it’s not suitable for the task at hand, limitations and restrictions should be listed too. Overall, these are the key attributes of a pattern, but there might be other attributes that can be added to specific patterns.

Using patterns is recommended, because it’s conventional and standardized, but sometimes we face unusual problems that require unusual solutions. If a solution is so unique, specific, and is not likely to be reused, it may not be a good candidate for a test pattern. This doesn’t mean that patterns discourage innovation in problem solving, on the contrary, a pattern can get replaced by a better one solving the same problem. So, sharing the better solution among teams, or better among a community members is a good opportunity to create a new pattern.

For more info: http://www.hwtsam.com and http://msdn.microsoft.com/en-us/library/cc514239.aspx

A very handy power tool is tfpt unshelve. It’s capable of migrating a shelveset from a branch to another, it does that by performing a baseless merge, so you will need to resolve the conflicts produced. The syntax of the command looks like the following:

tfpt unshelve shelvsetName /migrate /source:$/SourceBranch /target:$/TargetBranch

protected (C# Reference)

You can achieve that behavior by running:

tf hist rootItemSpec /r /version:LstartLabel~LendLabel

Here’s my scenario:

tf hist /i File.cs

Changeset Change                     User          Date       Comment

--------- -------------------------- ------------- ---------- --------

65        edit                       mohamedg      4/2/2009

63        edit                       mohamedg      4/2/2009

60        edit                       mohamedg      4/2/2009

59        edit                       mohamedg      4/2/2009

50        edit                       mohamedg      4/1/2009

49        edit                       mohamedg      4/1/2009

48        edit                       mohamedg      3/31/2009

47        add                       mohamedg      3/31/2009

tf label Rev1 File.cs;48

Created label Rev1@$/Proj

tf label Rev2 File.cs;63

Created label Rev2@$/Proj

tf hist /i File.cs /version:LRev1~LRev2

Changeset Change                     User          Date       Comment

--------- -------------------------- ------------- ---------- --------------------------------

63        edit                       mohamedg      4/2/2009

60        edit                       mohamedg      4/2/2009

59        edit                       mohamedg      4/2/2009

50        edit                       mohamedg      4/1/2009

49        edit                       mohamedg      4/1/2009

If you have an IDE that uses the MSSCCI provider, like VS 2003 or VB6, and you want to switch between TFS and VSS because you have projects on both systems, you will have to change the provider every time you switch. The thing is that setting is stored in the Windows registry, therefore, you will have to restart the IDE to enable the desired provider (just like most programs, unless they implement a registry watcher). There are some tools that can make the switch easier:

http://www.codeproject.com/KB/applications/sccswitcher.aspx
http://www.sitedev.com/sccswitcher
http://weblog.kilic.net/tools/SCPSelector

Or you may create your own .reg file to write to the registry.

TFS uses a temp folder to get files that you view. The location of that folder is %TMP%\TFSTemp. It’s not configurable via TFS, tf.exe, or Visual Studio. However, you can just set the TMP environment variable. Simply:

set TMP=D:\Temp
set TEMP=%TMP%
md %TMP%

Then you can starting using tf.exe afterwards and it will use the new %TMP%\TFSTemp instead, same thing with Visual Studio which can be started by running devenv.exe

If you want to change TFS temp folder on the server side too without changing the system temp folder, you have to have IIS7 installed; IIS7 loads user's profile by default for all application pools, including environment variables. Which means that the temp dir for the app pool is its user's temp dir, and you can change this value for that specific user only, not the system value.

Another temp folder on the server will be %TMP%\TFLogFiles. It’s used by TFS to log tracing info. This location is configurable in the global web.config, it’s an appSetting and its key is called traceDirectoryName.

A common scenario that you may see is the need to share/sync workspace mappings amongst team members. A developer adds a new dependency in a certain project and changes his/her mappings to get this library, and everyone else in the team now needs to do the same thing. Since workspace mappings are stored on the server, you can copy the mappings of any workspace to any of your workspaces, or create a new workspace using a template from another workspace. For example, let's say that you maintain the master workspace that everyone else is required to clone, once this workspace is changed, you can email your team so that they update their mappings. To view mappings of your workspace, they can run:

tf workspace /s:http://tfs:8080 WorkspaceName;DOMAIN\YourUserName

Then the workspace dialog will pop up and they can select all mappings (Ctrl+A) then copy them (Ctrl+C), then edit mappings in their workspaces by pasting the new mappings over the old ones.

Another option is to create a batch file that runs the same command above with the /i option, finds the mappings, parses them in a FOR loop to run tf workfold /map on each one, it should look like the following:

FOR /F "tokens=1,2,3 delims=:" %i IN ('tf workfold /s:http://tfs:8080 /w:MasterWorkspaceName;DOMAIN\YourUserName ^| find "$/" ^| find /v "(cloaked)"') DO tf workfold /map "%i" "%j:%k" /s:http://tfs:8080 /w:localWorkspaceName

Please note that if you run this command on the command prompt directly, variables like i should be written as %i, while if you run it using a batch file, it should be written as %%i

A common problem occurs when the drive that contains your workspaces runs out of disk space, or when you find yourself in a situation that you have to move your workspace to another drive. This might get tricky because your workspace mappings are stored on the server side. TFS knows about the local path and version of the items you have on disk, hence you can’t change the drive letter without telling the server that you did so. The easy way out is to maintain the same drive letter after you move the workspace to the new drive. Simply change the drive letter to the one used in the mappings, you can use compmgmt.msc (Computer Management) to accomplish that. If you can’t change the drive letter, for example if it’s the system drive, you can tell NTFS to link the old path of the root folder of your workspace to the new one using a junction. To create an NTFS junction point, you can download junction.exe and run:

junction <junction directory> <junction target>