Import Unit Tests to Test Cases

Using UI Automation and Unit tests in general is a good thing,
but VS does not provide a simple way of associating the tests to test cases.
you have to open a test case and associate the unit test, for one, two it ok,
for more then 10 its very tedious
in VS2010 we had a nice extesion called "Pronto",
in VS 2012 and above this does not work any more.

luckly the TCM command comes very handy here:
tcm testcase /import /collection:http://mytfs:8080/tfs/mycollection /teamproject:"myTeamProject" /storage:"fullpath_to_UT_DLL" [/filter:"test category"] [/syncsuite:"test suite id to update"]

this command will pass over all matching unit tests in the dll and add / update testcases.

MSDN TCM link : http://msdn.microsoft.com/en-us/library/ff942470.aspx

CodedUI - Running tests on remote machines

CodedUI is just one of many UI testing tools.
It's a great tool for testing UI although it has it's problems.
but this post does not talk about the problems or it's wonderful abilities.

I want to show you how you can run the codedui Test from a build machine or directly from VS2010/2012 on VMs.

first of all we need to install a Test Rig, meaning install Test Controller and Test agents
you can use the following link to do that: http://msdn.microsoft.com/en-us/library/vstudio/hh546459.aspx

P.S: since we are not using the Lab Management don't associate the controller with a collection. also make sure the test agent runs in interactive mode.

we then need to set up the test settings file to execute the test remotely and give it the test controller name.

set the test setting file as active


now we are ready to run the codedui tests and they will run on the VM.
but it fails, it says something about remote connection not active?
well yes one of the draw backs of running on VMs you need an active RDP connection and minimized is no good, it must be up.

luckily there is a workaround, every OS running as VM has a console session that is always open against the host. we use the following command to use it:
tscon RDP-Tcp#0 /Dest:Console

more information about TsCon: http://technet.microsoft.com/en-us/library/cc770988.aspx

just 2 things:
1. you are local admin on the machine (you need permissions on Console session)
2. after you run this command you are automatically disconnected!!!

because of option 2 i always add the video data collector
[image]
so i can see the test result. the CodedUI log is hard to decipher.

you will notice that the test if it failed was usually due to the low resolution of the console.
for this problem i created a special data collector that has the ability to change the resolution of the machine,
I created a "Change Resolution Data Collector".

https://onedrive.live.com/redir?resid=C4BEA458C5283F0B!270&authkey=!APVYd1IOyjoryDk&ithint=file%2c.msi

How To: Keep Test Items Deployment Structure

when using deployment items in tests we sometimes need to keep the stucture of test items as it appers in our local machine. by default the all the deployment items are copied to the same folder regardless the source location structure.

we can set the target destination by editing the "TestSettings" XML

all we need to do is update the DeploymentItem with outputDirectory attribute

 

here is an example for a folder:

<DeploymentItem filename="CoreSettings\" outputDirectory="CoreSettings\">

a small word of caution updating the XML will not show in the desginer until you reload the solution.


found at : http://stackoverflow.com/questions/10162436/visual-studio-2010-does-not-copy-folder-on-deployment-to-out-directory

Private accessors and TFS2012 Builds

sometimes old test containing privert accessors will fail the build with Error:

 

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamTest\Microsoft.TeamTest.targets (14): Object reference not set to an instance of an object.

 

first try to remove the private accessors and use a mocking framework (pex/moles or VS2012 Fakes)

But if due to any reason, you cannot remove the usage of private accessors immediately from your tests, please try changing the TeamTest targets file ("C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamTest\Microsoft.TeamTest.targets") and see whether running the shadow task in a separate process works or not.

Here are the steps you should do for this: -

1. Edit the targets file ‘C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamTest\Microsoft.TeamTest.targets’.

2. Change ExecuteAsTool property (highlighted) from default false to true.

<Target Name="ResolveTestReferences" Condition="'@(Shadow)'!=''">

  <BuildShadowTask

      ExecuteAsTool="True"  <!—Default value is false, change it to true –>

      CurrentResolvedReferences="@(ReferencePath)"

      CurrentCopyLocalFiles="@(ReferenceCopyLocalPaths)"

      Shadows="@(Shadow)"

      ProjectPath="$(ProjectDir)"

      IntermediatePath="$(IntermediateOutputPath)"

      SignAssembly="$(SignAssembly)"

      KeyFile="$(AssemblyOriginatorKeyFile)"

      DelaySign="$(DelaySign)">

 

    <Output TaskParameter="FixedUpReferences" ItemName="ReferencePath"/>

    <Output TaskParameter="NewCopyLocalAssemblies" ItemName="ReferenceCopyLocalPaths"/>

  </BuildShadowTask>

</Target>

3. Save the file. (and probably restart the machine as well so that the background msbuild processes definitely picks up the change)

 

this was taken from : http://blogs.msdn.com/b/aseemb/archive/2012/08/29/buildshadowtask-fails-with-error-c-program-files-x86-msbuild-microsoft-visualstudio-v10-0-teamtest-microsoft-teamtest-targets-14-object-reference-not-set-to-an-instance-of-an-object.aspx