TFS2010 database is growing fast (50GB per month) because of our TFS builds.
We noticed that tbl_attachmentcontent table contains some binary (dll) files and some files related to instrumentation and TQAgents... All content seems to be unit test related.
I tried to find something how to stop growing of TFS DB because of unit tests.
I found this suggestion to disable publishing of unit test results to the TFS.
How can I disable publishing of binary files to the TFS DB?
Is it possible to disable publishing of specific content?
What will be missing in the TFS when I disable publising unit tets results to the TFS?
At about 400+ unit tests are running every build including code coverage results and huge build log (500+ C# compiled projects with a lot of dependencies).
I'd like to have build retention policy set to "Kepp all", because of build statistics.
I did some testing and here are the results:
1) You can disable unit test publishing. Your unit tests results file (trx) is not uploaded to the TFS DB. This is not problem for me, because I'm using Trx2Html tool to convert results to the HTML format. If test failed, converted HTML formatted report is sent by E-Mail to notify developer team.
2) You can enable compression on the dbo.tbl_AttachmentContent table. In our case compressed content is 5% from original.
3) Use this tool to clean up dbo.tbl_AttachmentContent table
All I know that test result is not a binary file, but it's XML file with (.trx) extension, for your question about what happen if you stop publish test result, the build server just attache the test result with the build so you can view the result by click on the test result on the build result, so you just download the file and start viewing the result by the visual studio, otherwise you will not be able to see it.
This is what I think.
Update
You can see this link:
http://blogs.msdn.com/b/anutthara/archive/2011/10/30/gsjgd.aspx
Related
We have a TFS build definition that kicks off NUnit tests tagged with the 'Regression' test category. This uses the NUnit console runners annotation of
where cat = 'Regression'
However, we have multiple different environments where some tests will fail in one environment, they will pass in the other. We have not made much use of the Playlist feature, because I can not find a way to target a playlist when running remotely on TFS. Does anyone know how this can be done? Thanks!
Unfortunately, there is no way of specifying this/playlist in the TFS Build Definition for now. A related uservoice:
Allow test playlists to be used by TFS build servers
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/3853614-allow-test-playlists-to-be-used-by-tfs-build-serve
As a workaround, you could use .orderedtest instead of .playlist.
Ordered tests can be created and edited in VS2013 and later. The format is otherwise similar to .playlist but it contains links to test GUIDs so its more complicated to modify programmatically.
TFS is able to run orderedtest in build pipeline, how to achieve this you could refer below links:
TFS - order of automata tests to execute
How to use Vnext build: ordered tests, distribute test, collect results
I've been trying to get Jmeter load tests to run in VSTS thus far without avail. I've been back and forth (very slowly!) with the Microsoft support team about this, but as the issues are ironed out I would like to at least run a small set of load tests on our build machine using Jmeter and then have the results uploaded somehow to VSTS so they are easier to track. I have part 1 of this working: From the VSTS release definition I run a batch file that runs the load tests locally, and then generates an aggregate spreadsheet with results.
The question is - how can I get those results loaded into VSTS?
In our case we had to export the results to xml using the jmeter.test.xmlouput configuration. Then we had a script to transform the xml in a proper Xunit result file and we finally used a publish test results to gather this file and add the results to the release. (this approach would work with build definitions too).
It's a little bit complicated, requires some scripting and surely would be easier if a dedicated task was available.
so I set up a none-XAML-build on TFS 2015 to build and test my Maven project. Which works as expected. Then I added a build step to consolidate test results via **/TEST-*.xml and publish them as a test run to tfs, which also works, but...
on the testrun summary page it shows the correct number of passed tests and it also attached the JUnit XML-files, though on the test results page it does not show anything :( Those .xml-files are JUnit <testsuite> results with multiple <testcase> entries and I expected for TFS to display the result for each individual test including it's duration, but it does only show a blank page.
Anybody has the same problem or even a solution (except publishing by tfs api :p) Cheers!
There are no additional settings to show the test result info. It will automatically show the every detail information about each test.
Since the test run summary show the right info. The test must run successfully. Please check your build log whether there are some valuable info. And also double check your build template configuration. Here is a blog telling you how to use vnext build with Marven and run the tests for your reference:
Building Java code on Linux using VSO Build.vNext
I was working on team internal KPI's lately and I thought that code coverage/number of unit tests will be a great measure.
In our CI build pipeline we're using NUnit to run test and JetBrains dotCover to generate coverage report - everything works great and we have that fancy "statistics" page in Team City control panel:
What I would like to do is to export this coverage data so I can generate HTML output for the current coverage status and keep it under control not necessarily in the Team City console?
Thanks in advance.
For any reports that teamcity shows, the convention is that it needs a zip file with an index.html page at the root. So for coverage report it would be coverage.zip and so on.
If you go the workout directory for your builds, you can find the artefacts that you want (coverage, test results etc) in the artefacts folder.
I work with Coded UI Tests and Visual Studio 2013. Now I have to test if images from a folder are shown correctly inside the application. That’s why I have created a folder containing the images and set build action to none and deployment to always.
Unfortunately all tests are executed in an own test results folder and my images are not deployed correctly. I know I could do this by using the DeploymentItem attribute or a testsettings file but I don't want to do this. I want to avoid the "test results" folder and run the tests from within the output folder of my test project.
I do this with the unit tests for instance. They are written with XUnit.Net which works just fine. I thought it would also work with MS Test but this only seems to work for Unit Tests but not for Coded UI Tests.
So, to sum it up again: How can I get rid of the “Test Results” folder when using Coded UI Tests with Visual Studio 2013 and run my tests simply from within the output directory of the project?
You can do this using a custom entry in the .runsettings file I think.
DeploymentItemAttribute Class
Consider running your unit tests directly in the build output
directory, so that testing runs more rapidly. This is especially
useful on the build server after you have checked in your tests. To do
this, add a .runsettings file to your solution, include
False, and select the file in
the Test, Test Settings menu. The same effect occurs in any test run
in which DeploymentItemAttribute is not used at all.
However, you
might prefer not to do this if you want to be able to inspect the data
files after a failed run.
You cannot avoid using a deployment folder
if you are using a .testsettings file, which is required for web and
load tests, coded UI tests, and any test in which you deploy an
application to remote machines.
As for DeploymentItemAttribue itself I would steer clear of it unless the following issues have been fixed, Gotchas: MSTest’s [DeploymentItem] attribute. +1 for xUnit in TestDriven.NET.
You can try deleting the LocalTestRun.testrunconfig file from the Solution Items folder (directly under the solution). When we did that it started using the \bin\debug\ folder instead of the TestResults folder when running our unit tests using MSTest.