I'm about to deploy a soapui project that is made in the soapui PRO version. Must i have soapui PRO installed on the build server which rund TFS to be able to run the tests?
Since there is no TFS integrated with SoapUI, you may need to install the SoapUI on your build server.
You can call your test using a bat file, add this bat file to your source control so that it is carried accross with the build.Then Add an invoke process to your build template and then call out to the SoapUI test runner.
Here is a bolg telling you how to include SoapUI in your CI build cycle:http://blog.simplecode.eu/post/Soap-UI-testing-with-MsTest
Related
I'm trying to create a release pipeline in VSTS that runs my xUnit-tests as specified in a Test Plan.
Long story short: I can't get it to work.
What I'm using:
Azure DevOps (formerly VSTS)
Visual Studio Test task (v2.*)
Test project targeting .NET Core 2.1
xunit 2.4 with xunit.runner.visualstudio 2.4
In Azure DevOps I defined a Test Plan that contains a Test Suite which contains a Test that has an Associated Automation which points to my xUnit test.
I had to use the REST API to link the test code to the Test as described here.
I can select that Test in the visual designer for the VSTest task.
When I run the release pipeline the VSTest task fails with the following error message:
DiscoveryMessage : System.IO.FileNotFoundException: Unable to find tests for D:\a\r1\a\Foo.Tests.dll. Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk" and framework version settings are appropriate. Rerun with /diag option to diagnose further.
The path to the Foo.Tests.dll is correct, all required files are copied as well.
I explicitly specified the framework version in a .runsettings file (as the option Other console options doesn't work when using the Test plan option).
Specified the path to custom test adapters
used Visual Studio 2017 and Installed by Tools Installer options
Added a .NET Core Tool installer to install the correct .NET Core SDK
...and any other combination of settings I could think of.
The error message is still the same.
Any ideas what I might be missing? Your help would be greatly appreciated at this point!
After several more hours we stumbled across a web page that stated that you don't have to copy the binaries of your test project as input for the VSTest task but PUBLISH it instead. That never came to mind as vstest.console.exe runs smoothly when you point it at the binaries on a local machine.
UPDATE: We had to add a Publish Artifact task at the end of our Build Pipeline and make the Release Pipeline pick up the published artifact.
I'm trying to run MQTT test using JMeter on Jenkins. I've integrated maven and used Github repository to run the script. The problem is when i try to run a simple API test, jenkins automatically creates a .jtl file(provided that i've added post build action) In case of MQTT test script, Jenkins Build is successful but the test fails showing this error " no JMeter files matching '*.jtl' have been found.". Why is it so???
Do you use Jenkins performance plugin? If not you should do it.
Do you run JMeter in the Non GUI mode? If not you have to.
In this article how to run JMeter with jenkins you'll find step by step guide for Jenkins configuration for launching JMeter tests.
I have a question that's very similar to what's discussed here:
Integration Test of REST APIs with Code Coverage
I deployed a war file that exposes the REST APIs to a web server and I'm using TestNG to write test cases for the REST APIs. I'm not unit testing - I'm only end-to-end / integration testing. Currently, I'm running test cases from eclipse in my machine.
My goal is to get coverage reports on the TestNG test cases.
Since the tests are local to my machine and the REST API is deployed in another server, EclEmma doesn't provide any meaningful data when I run the tests cases in my machine.
Is there a way to point EclEmma to the web server instead of my local machine and get the code coverage report?
Would it be better/possible to include the tests in the war file and run the tests from the web server? That should allow me to get the meaningful code coverage report, right?
The easiest way forward in cases like this is normally to start the web server inside of your IDE and run tests with coverage measuring in there. Even better to start the web server from within the tests - then a build tool like maven can also do code coverage reporting.
I have setup continuous integration for a WCF project and want to use the MSBuild Arguments to automatically deploy the application to a remote server but it is not deploying.
When running a new Build all the Tests pass and all the projects build but the website is not being deployed. Also, I am getting no errors back from the build to say anything has gone wrong.
I have opened up port 8172 on the remote server to ensure connections can be made to IIS and have even disabled the firewall.
In the Build Configuration I have specified the following arguments;
/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:DeployIisAppPath="Default Web Site/MYSite" /p:MsDeployServiceUrl=http://mysite.com /p:username=MySite\Administrator /p:password=thePassword
I compiled this configuration from the following examples:
http://vishaljoshi.blogspot.co.uk/2010/11/team-build-web-deployment-web-deploy-vs.html
http://www.chrissurfleet.co.uk/post/2011/07/21/Setting-Up-Continuous-Deployment-In-TFS.aspx
I have configured the Server's IIS to enable remote connections and I can Remotely administer IIS from the build server. Also I have successfully deployed the Application using Visual Studio 2012 Publish option.
can anyone see a problem with my MS Build Arguments? Am I missing anything?
Any help would be very grateful
Update:
I have checked the build server to check MS deploy is installed and have installed Web Deploy 3.0 to ensure this is capabale, but has not solved my problem.
I have check the IIS connection logs to see if the remote connection to IIS is being made and there is no connection being made from my build server to the app server.
I have tried running MSBuild.exe for the solution and project on the build server manually with the following:
MSBuild.exe "Project Location" /p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:MSDeployPublishMethod=WMSVC /p:DeployIisAppPath="Default Web Site/app" /p:MsDeployServiceUrl=http://appserver:8172/MSDeploy.axd /p:AllowUntrustedCertificate=True /p:CreatePackageOnPublish=False /p:Username=username /p:Password=password
The MSBuild is successfully building the project but is making no attemp to deploy it.
Any Ideas?
Turns out the problem was files were missing on the Build Server as desibried in the Answer to this question:
Similiar problem
Also when installing Web Deploy 3.0 using Web Platform installer not all the features required are installed in order to connect remotely to IIS through MSBuild command line.
I copied the nessesery files from my dev machine to the build server and installed Web Deploy 3.0 manually with all features and this now works!
Maybe there is a bug with TFS 2012???
Just went from TFS 2008 to 2010 at a client site and now wondering what happened to the TFSBuild.proj files from the TeamBuildTypes folder. I've already got the builds and drops working and now I need to get the old deployments working again. We used to do this with AfterBuild targets in the TFSBuild.proj. That mechanism seems to have moved or disappeared in 2010.
Can anyone point me to an article or describe how the deployment options have changed in 2010?
Specifically, I need to support running psexec to install and enable Windows Services on remote deployment targets and I need to deploy some web sites / web services to remote IIS nodes as part of the automated builds.
EDIT: Just found this: http://blogs.msdn.com/jimlamb/archive/2009/11/03/upgrading-tfs-2008-build-definitions-to-tfs-2010.aspx I'm more than a little taken back by the breaking changes between 2008 and 2010. I'm gonna need advice on how to deploy remote sites and services in the new default build process template mechanism.
Check out Vishal Joshi's PDC talk on Deploying Web Applications with VS 2010 and MSDeploy. On his blog, you'll also find tips on building MSDeploy packages with MSBuild. You can run psexec from your MSBuild script or, potentially, from a customized build process template. With TFS 2010, you can use MSBuild and Windows Workflow to solve your build automation problems.
Alternatively, you can use the "Upgrade" build process template and continue using your TFSBuild.proj file. This is the default behavior for upgraded build definitions for backwards compatibility. In that case, your build is still primarily driven by MSBuild with just a thin workflow to allocate an agent and run MSBuild.
Another option is to use TFS 2010 Build Agent on the server that you deploy to. This is how Visual Studio Lab Management deploys.
I have written a blog post about this: Continuous deployment with TFS 2010 Build Agent