I have created an ANT build for an eclipse project and its associated unit tests using Team Foundation Server 2010. However I am having trouble getting it to publish the results of the unit tests to TFS.
The build.xml file itself seems to function correctly in that it builds the project and creates an xml results file. The issue seems to be within the TFSBuild.proj and the publishing of the test results to TFS.
Using the following code, the build executes successfully and publishes the results to TFS as I would expect:
<ItemGroup>
<AntBuildFile Include="$(SolutionRoot)/StockMoves/build.xml">
<Targets></Targets>
<Properties>BinariesRoot=$(BinariesRoot);BuildDefinitionName=$(BuildDefinitionName);BuildDefinitionUri=$(BuildDefinitionUri);BuildDirectory=$(BuildDirectory);BuildNumber=$(BuildNumber);DropLocation=$(DropLocation);LogLocation=$(LogLocation);SourceGetVersion=$(SourceGetVersion);TestResultsRoot=$(TestResultsRoot);TeamProject=$(TeamProject);WorkspaceName=$(WorkspaceName);WorkspaceOwner=$(WorkspaceOwner)</Properties>
<Lib></Lib>
</AntBuildFile>
<JUnitLogFiles Include="$(SolutionRoot)/StockMoves/test/TEST-unittest.TestSuite.xml" />
</ItemGroup>
However, when attempting to change the path in which JUnit looks to this:
<JUnitLogFiles Include="$(SolutionRoot)/**/TEST-*.TestSuite.xml" />
Then the test results are no longer published. I know this formatting works as I've successfully used it in other builds but this one has me stumped.
Any help would be greatly appreciated!
It looks like I've solved this!
It would seem that for whatever reason, that the file in question must already exist when the build is run. I added an empty xml file with the same name as the file produced by my test results and now the results are published to TFS.
Related
I am trying to run a Eclipse java cucumber project in TFS (which has set of feature files).
After running successfully in TFS, the TestCase title appears as "feature" for all the TestCases. Unable to see which test scenario was run.Though I can see the feature names appearing in the log, those names does not appear in Result. It would be great if someone could help with setting up the TestCase title in TFS.
Since TFS was picking junit report , I was finding this issue.
I updated my result file pointing to cucumber created junit unit report. It worked fine for me. Updated the test runner file to create the junit report -"junit:target/surefire-reports/TEST-TestSuite.xml" and pointed TFS result file to target/surefire-reports/TEST-TestSuite.xml.
Code below.
#CucumberOptions(
features= {"src/test/resources/Features"},
plugin = {"pretty:STDOUT","html:Reports/cucumber-pretty",**"junit:target/surefire-reports/TEST-TestSuite.xml"**, "com.cucumber.listener.ExtentCucumberFormatter:Reports/Reporting/Quixxi_Report.html"},
monochrome = true,
dryRun=false
)
I'm tired of not knowing what builds web application is built from when an issue is presented to me by QA. My proposed solution is to generate some static content as part of the build process that has useful information in it. Somebody could reference that file manually on the server and I think it would be nice to offer the ability the HTTP GET the content as json perhaps as part of the API.
Seems simple right? I've done a lot of looking into doing this with Subversion in the past but I'm not familiar with the options for TFS. I realize that I'm really looking for two things, one to harvest the TFS information such as the repository, branch, changeset number, ... as well as a way to write content to a file all within a standard build process. Are there any existing MSBuild targets or tools I can pull in using something like Nuget to ensure that this is done for all builds whether they are local dev builds or ones done through a CI server which don't require any extra configuration or steps by the dev or the one setting up the CI server environment? What I'm hoping is that this is a common enough pattern that maybe somebody has already done this exact thing and packaged it for reuse or that the pieces are simple enough to piece together in a way that can be repeated as a general pattern for various types of .NET projects.
UPDATE: I realized that one issue with the proposed solution is that whatever static file is generated, it would have to be added as a reference to the project in order to be picked up by the build process as content so that it is copied/published properly along with the rest of the web application. Perhaps a broken reference can be added to the project ahead of time that would be fulfilled after the project is built at least once. This is reminiscent of the old way that Package Restore used to work with NuGet.
Related resources:
MSDN - Code Generation in a Build Process
StackOverFlow - MSBuild to copy dynamically generated files as part of project dependency
StackOverflow - How to programmatically get information about branches in TFS?
StackOverflow - It is possible to get TFS change set number from the local file system?
StackOverflow - tf.exe info /version:T does not get latest
The version control information is already generated in environment variables, you just need to write some simple command to read them from the environment variables. Check following links to see if these information meets your requirement:
For vNext build: Predefined variables.
For XAML build: TF_BUILD environment variables.
To include the generated file, you can refer to this question for details: How do you include additional files using VS2010 web deployment packages?
Here is what I've come up with which is working for now:
<Target Name="BeforeBuild">
<PropertyGroup>
<ProgramFiles32>$(MSBuildProgramFiles32)</ProgramFiles32>
<VS14Dir>$(ProgramFiles32)\Microsoft Visual Studio 14.0</VS14Dir>
<TF Condition="Exists('$(VS14Dir)')">$(VS14Dir)\Common7\IDE\TF.exe</TF>
<TfCommand>"$(TF)" vc info . > version.txt</TfCommand>
</PropertyGroup>
<Message Importance="High" Text="Creating version.txt: $(TfCommand)" />
<Exec Command="$(TfCommand)"></Exec>
</Target>
<ItemGroup>
<Content Include="$(SolutionDir)\version.txt">
<Link>%(Filename)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
This invokes the tf.exe console application with the args vc info . which gets version control information for the current directory and then uses >> version.txt to pipe the output to a file. There are a probably a bunch of improvements that could be made on this but it's a start. Next, I'll have to find some way to include the generated version.txt file as content within the project.
UPDATE: It looks like tf info only gives info about the specified directory and not about the working copy. I'm looking around for alternatives again.
We have upgraded to TFS Update 2 release management recently. Enabled code coverage in Visual Studio Test as show below.
Build runs successfully and show test cases execution result.
But I dont see Code Coverage information. Do we need any other configuration?
UPDATE:
I tries detaching the collection, but no luck.
In your build definition you specify using .runsettings file for Code Coverage. So when Code Coverage is ran it loads the collectionscodecoverage.runsettings file and returns result depending on whats in it. Most likely .runsettings file is not correct.
You can collect Code Coverage without having a settings file. Just leave the "Run Settings File" option empty on build definition.
To validate that your .runsettings file is correct - run Code Coverage locally from Visual Studio having .runsettings file set as default test settings file. See details here.
Another possible problem addressed in this post.
I am trying to implement continous build process, if i look at the XAML in the sequence Drop Folder I want to specify a custom template
that is I do not want all the files to be dropped in one folder,
I have to create a folder structure like Folder1, Folder2, inside root folder.
Based on file extension files have to be dropped to particular foldder
any point how to achieve this,
If you're happy modifying the TFS build templates then Torbjörn's answer is definatly the way to go. Customising the build template will give you complete control of the output. However this can be overkill, especially if you're not familiar with WF and the internals of Team Build. An alternative is to write some msbuild which will run as part fo the build.
To do this create a file called "DropTidy.proj" and edit the file so that it looks something like this
<Project DefaultTargets="CopySQLReleaseFiles" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<Target Name="CopySQLReleaseFiles">
<ItemGroup>
<SqlBuildOutput Include="$(OutDir)\*.sql" />
</ItemGroup>
<Copy SourceFiles="#(SqlBuildOutput)" DestinationFolder="$(OutDir)\SQL" />
</Target>
</Project>
The example above will copy all files with an extensions of "sql" in to a folder called "SQL". $(OutDir) is the working folder used by team build that relelates to the "Binaries" folder in the build workspace on your build agent
Check the file in to TFS and then add it to your "Items to Build" list in the Team Build Definition. Make sure that it's the last "Solution" in the list so that it runs after the other solutions in your build. Also make sure that the folder you checked the proj file in to is part of your builds workspace.
Run your build and you should see a new folder called SQL in your drop location.
If you're using the default build process template (or a derivative of), the actions for copying to DropFolder are inside Finally block of Try Compile, Test and Associate Changesets and Work Items. You will have to replace that single Copy to Drop Location action with your custom sequence. The FindMatchingFiles can be used to select a set of files based on a search criterium.
One problem will arise when trying to copy single items; TFS build activities does not have an action for that; only for CopyDirectory. You can set up a InvokeProcess, alternatively add Community TFS Build Extensions from where you'll get Robocopy and Powershell actions to support such tasks.
If you're using the basic DefaultTemplate, I'd strongly advise you to make your changes in a copy of it and use that for your builds.
I've got an MVC web application with associated controller tests that run under a TFS build as per normal.
I can see the tests running and passing in the build log and they appear in the "Result details for Any CPU/Release" section of the build
I also have a number of other assemblies with associated tests that are running in the same build. Tests are passing and the details are being shown in the results and logs just fine.
I've enabled code coverage in the build script and the testrunconfig.
The coverage is appearing for all assemblies EXCEPT the web application even though it looks like the tests have been run for it.
Is there anything obvious that I have missed or some sort of work around that I need to do?
I've searched around for a while and haven't found an answer.
Has anyone got code coverage working for MVC web applications using TFS?
After reading the article posted earlier I thought I would try an alternate approach.
looking at the localrun.testconfig in a text editor I saw that the assemblies that contained code coverage data were in the section below
<Regular>
<CodeCoverageItem ... />
<CodeCoverageItem ... />
</Regular>
The only reference to a web project was in the section:
<AspNet>
<AspNetCodeCoverageItem id="..." name="..." applicationRoot="/" url="http://localhost:0/" />
</AspNet>
So to get code coverage working in TFS:
In VS IDE, double click the localrun.testconfig, then click Code Coverage and then manually add the MVC assembly by clicking the Add Assembly... button. You will get a warning message about duplicate assemblies, tell it to use this new file.
What this does behind the scenes in the localrun.testconfig is add a CodeCoverageItem
entry with the MVC assembly and removes the AspNet section from the CodeCoverage section of the file.
This has the added benefit of not starting up a local web server every time you run your tests.
But it may have a detrimental effect on any Watin type tests and coverage.
Team Build, Code Coverage and MVC by Richard Fennell looks a pretty detailed hack.