Hello All,
I have some tests list like
- Release 1
- Iteration 1
- TU (stands for Unit Tests)
- TR (stands for Acceptance Tests)
- Iteration 2
- Release 2
- ...
I would like to run first all my Unit Tests and then all my Acceptance Tests. If I reorder my tests lists to have something like
- TU
- Release 1
- Iteration 1
- Iteration 2
- TR
- Release 1
- Iteration 1
- Iteration 2
I then can reference my tests like
<MetaDataFile Include="$(SolutionRoot)\DH2Solution\DH2Solution.vsmdi">
<TestList>TU</TestList>
</MetaDataFile>
<MetaDataFile Include="$(SolutionRoot)\DH2Solution\DH2Solution.vsmdi">
<TestList>TR</TestList>
</MetaDataFile>
But I would prefer not to reorder my test lists. I have tried with <TestList>*/TU</TestList> or <TestList>TU</TestList> but it doesn't work
Second question :
Then it generates two tests run in my build report. That's perfect, waht I was searching for. But my problem is that both tests run have the default naming scheme. Can I give a specific naming scheme for each test run I have seen that in the testrunconfig file but this is for all tests run and not for a specific one.
Thanks !
Test run name and test list
Father Fil
No idea
Note that the current naming scheme is "{user}@{buildMachine} Date"
So I imagine there are some "placeholders" or macro we can use to generate a name. If it is the case, where can I find this list
Thanks,
Peter007
Hi Jarod,
Adding on to Amit's answer...
While specifying naming scheme is supported with test run configuration, there can only be one test run configuration per vsmdi, and Team Build does not support specifying a different test run configuration for each test run. So the only option left is to specify two different .vsmdi's, each pointing to a different test run configuration.
However, while you can have more than one test run configuration in a VS solution, you can only have one .vsmdi at any one time. In order to create more than one .vsmdi file, you will have to cheat a bit. For example, after setting the desired test run configuration (with the naming scheme you want) to be active, you save the vsmdi file and check it in. Then you remove the vsmdi file from the solution. On disk, make a copy of the vsmdi file, then add the new copy to the solution. Now set a different test run configuration (with the naming scheme you want) to be active, and check this new vsmdi file in. This results in two different vsmdi files in source control, each pointing to a different test run configuration (I am not sure if the original vsmdi will be removed from source control. If it does you will have to re-add it in source control explorer.)
I realize this is definitely not ideal, and it's not easy to maintain. I thought I'd still mention it anyway as a workaround if you are interested. We will definitely look into supporting this in our next version.
Thanks!
Winnie
smhmp
Hi Jarod,
1) To run the two sets of tests separately, you will have to list them out explicitly:
<MetaDataFile Include="$(SolutionRoot)\DH2Solution\DH2Solution.vsmdi">
<TestList>Release 1/Iteration 1/TU;Release 1/Iteration 2/TU.....</TestList>
</MetaDataFile>
<MetaDataFile Include="$(SolutionRoot)\DH2Solution\DH2Solution.vsmdi">
<TestList>Release 1/Iteration 1/TR;Release 1/Iteration 2/TR.....</TestList>
</MetaDataFile>
Sorry that we don't have a more flexible approach to solve this scenario in v1. We will definitely look into this more in the next release.
2) This can be accomplished by specifying test run config file. I am following up with devs in the Team build team to find out how this can be done.
Thanks!
Winnie
YathiRajaRao
Jarod,
By specifying the naming scheme in the test run configuration file, you can choose to use customized naming scheme. So, creating two test run configurations with different naming scheme would get you the result.
Unfortunately, in the current version during a Team Build, we only use the default run configuration file for the vsmdi, so you will not be able to provide different run config file for each test run and achieve this result. All test runs for a vsmdi will use the same run config file.
Thanks,
Amit