My ASP .NET Solution (net framework 4.7.2) consists of several projects. I am interested in having a build definition (Azure) that will run my tests from a specific folder ( that folder contains some tests projects -nunit tests )
I have searched for information about this, but most solutions seemed constructed towards building & releasing, with all the tests in the whole solution being run.
How should I approach this? I will need to build my solution (Visual studio build ) as a task (?), but what should be the steps(tasks) to select and run my test folder ?
You could actually do something like this How to run a list of tests with VsTest.Console on windows agents if you prepare such file with list of tests from that folder.
You can find vstest.console.exe on this location on host agents
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\TestPlatform\vstest.console.exe
In that case you just need to prepare such file, put it in source control and run in your pipeline.
I will need to build my solution (Visual studio build ) as a task (?)
The answer is yes. That because the folder **\bin\** is ignored by source control by default. We need to build the solution in our build pipeline to generate dll files.
but what should be the steps(tasks) to select and run my test folder ?
We could specify the specific folder in the Visual Studio Test task in the Search folder:
Or specify that folder in the option Test files:
Related
I am trying to configure and run selenium test cases from Azure Devops Release pipeline. I did configure Visual studio Test Platform installer followed by Visual studio test. However, while running the 'test task', its erroring out stating
2019-12-22T11:31:50.7602521Z ##[warning]No test sources found matching the given filter '**\*csproj'
Am I missing something here or not doing proper configuration?
My main test case is being written in .cs file and tried including it in path as well but still same error.
Can someone please guide me?
thanks,
Pankaj
You have to add the path to the assemblies - dll. cs files are not used here as they are not compiled.
Provide the search pattern in the Test files field
Example search pattern:
**\publish\Test.Project.Name.dll
!**\*TestAdapter.dll
!**\obj\**
Have you built your project? Since you said you can see only files which are .cs or .csproj. You should first build your project to generate .dll files which are used in your vstest test files.
You can add the Visual Studio Build Task above the Visual Studio Test Task, then choose your project(.csproj or .sln) in the Solution Tag.
After building, you will see the .dll files in your Artifact, then, as Jonah said, you need to specify the location of the .dll file in Test files.
I have a test plan(Contains test cases linked to UI tests. hence automated). To run them, i have linked them to a release definition(Continuous deployment). All tests pass, but not UI.
I understood that it does not have an .exe to run. Hence, i've made sure that necessary files + .exe from project's bin folder gets copied to UI project's bin folder.
But, when I see the output in server while creating release, only, dll of test project was copied not .exe files.
I need help in writing my release definition to run all test plans and deployment. I've used TFS 2017, vsTest(version 2), VS 2017
I am have built an MSBuild project that has
the main .proj file with several Targets inside,
several .targets files
and several .rsp response files to run this project in several ways. Such as
Build, Clean/Build/Deploy, Clean/Build/Test/Deploy.. You get the idea.
What I now want to do is take this MSBuild and run it in TFS scheduler after I pull the source code. So the workflow should be
1. Pull the source code in TFS
2. Run MSBuild project in the scheduler so I might set up tasks to run hourly and nightly.
The MSBuild will take care of Deploying to IIS, unless someone has a more efficient way of deploying after an hourly build.
How can I accomplish this in TFS?
Thank you
You can use the Team Explorer UI in Visual Studio to define a "scheduled" build definition.
http://visualstudiomagazine.com/articles/2012/04/11/creating-a-build-definition-in-tfs.aspx
If you want to take this to the next level, research "continuous integration" which is also a built in capability.
Just wondering if there is a preference between sln or csproj files when building projects in TFS 2012. We typically build sln files in TFS to support our dev teams and that's usually the standard, but one team is asking why we can't build csproj files instead in TFS.
I noticed that to build a csproj file you have to provide arguments in the MSBuild Arguments field for a TFS build definition, and you do not have to provide these arguments when building a solution file. So other than this small detail I'm not sure what the pros and cons are between building an sln vs csproj.
Can someone please shed some light on the benefits, pros/cons of building a sln vs csproj in TFS, is there a common practice, a standard, or does it really matter?
Just wondering if there is a preference between sln or csproj files
when building projects in TFS 2012. We typically build sln files in
TFS to support our dev teams and that's usually the standard, but one
team is asking why we can't build csproj files instead in TFS.
Why do they want to do this? Is there some sort of advantage articulated in this inquiry?
I noticed that to build a csproj file you have to provide arguments in
the MSBuild Arguments field for a TFS build definition, and you do not
have to provide these arguments when building a solution file. So
other than this small detail I'm not sure what the pros and cons are
between building an sln vs csproj.
A .sln is a master project that is converted to an msbuild script at runtime and will use a metadata file using the same schema as the .csproj projects in your solution.
To see what I'm talking about, open a command prompt, type "SET MSBUILDEMITSOLUTION=1" then "msbuild.exe solution.sln", then parse the new "solution.metaproj" and "solution.metaproj.tmp" files.
Can someone please shed some light on the benefits, pros/cons of
building a sln vs csproj in TFS, is there a common practice, a
standard, or does it really matter?
A .csproj would be a single project while a .sln would be a collection of projects. Building a single .csproj would yield the output binaries of that project (along with dependencies) and building the entire solution would yield the outputs of the entire solution.
I had the same question. Build times may be a bit slower but I haven't tested this myself (probably a negliable difference). I believe that when you build using the solution file it will automatically set 'BuildInParallel' to true.
Faster Buidls with MSBuild
I am currently working on the TFS 2012 deployment build. Based on what I experience, you don't have to provide MSBuild Arguments unless it is really required.
Lets take the following example: You have a solution with 2 projects,
Soln
> Web Proj 1
> Console Proj 2
> Dependency Library Folder
case 1: building a sln
a. In source settings, you have to mention only your solution folder. The MSBuild will automatically take care of any dependencies as they are within the solution.
b. In Process -> Items to build, you have to mention your solution file.
c. For example, if your solution has a web project, then the MSBuild output will be as shown below,
\\<build server> \d$\Builds\<Build Name>\<Build File Name>_20141210.6\_PublishedWebsites\<web proj>
Case 2: building a csproj
a. In source settings, you have to mention only your csproject folder and also the dependency folder path separately.
b. In Process -> Items to build, you have to mention your csproject file.
If you are looking for something more specific, please let us know.
I recently finished a solution composed by 2 project. For this 2 project I have the .exe build, but I don't know how to do the exe of solution with VS 2012. Someone know how to do it?
When you compile & build a solution, the .exe that is created is placed into the folder relating to your current build configuration, usually either Debug or Release.
So navigate to the folder, on disk, using Windows Explorer, where the solution is stored, and look in the Debug folder. The compiled program is there.
If this is not what you are after, please post more details about these two projects and how they 'tie together'.