we are currently using Wallaby.js for javascript unit testing. Works fine and is great. But within our development pipeline we of course want to run the same tests on the build server - in our case a tfs.
Is it possible to use wallaby on a tfs build server? Anf if yes how?
If not, what is the way to go to run the wallaby configured unit tests on the build server?
As we used the karma test runner earlier, I tried to execute the new test configuration with it but then I get
Can't find variable: wallaby
as in our main/ starting test file it is written
wallaby.delayStart();
require.config({
baseUrl: 'app',
(Originally from a karma/ requirejs configuration)
How to get around this?
Has anyone experience in this scenario?
Wallaby.js main idea is to integrate with editors, run tests for the code that you change and display the results in the editor. You can't use Wallaby.js in a CI build.
You may consider invoking other test runners, or use grunt/gulp task instead for javascript unit testing.
In TFS 2012 and later (might work in 2010 but not sure) you can extend the testing capabilities of the build system.
Check out these posts -
http://www.aspnetperformance.com/post/Unit-testing-JavaScript-as-part-of-TFS-Build.aspx
https://blogs.msdn.microsoft.com/visualstudioalm/2012/07/09/javascript-unit-tests-on-team-foundation-service-with-chutzpah/
Related
I'm possibly in over my head here, but I've been asked to set up a scheduled Team Foundation Build for our team's branch and then after the build completes for our automated tests to be executed using NUnit.
I've had a look at a few online tutorials on setting up the build definition in TFS, but I can't seem to figure out how to call NUnit after the build is successful. I was expecting to see or find some kind of "run this command line on success" option somewhere; the best I could find is "Pre/Post-test script path", but that's related to tests like **\*test*.dll;**\*test*.appx and I'm not sure what that is.
Just knowing what to Google for would be a help, as I am at a loss now.
If you use XAML build:
You can either install the NUnit Test Adapter NuGet package in the unit test project. Or you can check the assemblies into the Build Controller's Custom Assemblies Path.
Useful article:
https://blogs.msdn.microsoft.com/visualstudioalm/2013/06/11/part-3-unit-testing-with-traits-and-code-coverage-in-visual-studio-2012-using-the-tfs-build-and-the-new-nuget-adapter-approach/
https://www.codit.eu/blog/2015/03/18/continuous-integration-with-javascript-nunit-on-tfsbuild-part-3-of-3-/
If you use new task based build:
You can add the NUnit Test Adapter NuGet package to your solution, and specify the path of NUnit Test Adapter NuGet package in the Path to Custom Test Adapters field in VSTest task. Check the screenshot below:
Useful article:
http://bartwullems.blogspot.sg/2015/10/team-foundation-server-2015enable-nunit.html
I had this working on a previous project and now on a new project I've setup SpecFlow, got it generating tests from my feature file but I can't run the tests from the feature file and instead have to go to the code behind to run the tests. I've also installed the VS extension "Spec Flow for Visual Studio". What can I try?
as Greg suggested the first thing to check is that your config is set up correctly for ms test. you basically need this:
<specflow>
<unitTestProvider name="MSTest"/>
</specflow>
Also worth checking your generated feature.cs tests to see what unit test language they are in
I finished writing Atuomation scripts(using selenium webdriver) for IOS Application.
Now how can i release it to client (Or) how to release a build and how to run scripts once again
Selenium is code. You should follow standards for releasing/branching of code and then setup your client with access to the code. Since it is code I would recommend creating an instruction doc on how to get the latest and how to execute the code through whatever execution mechanism you guys are using...i.e. unit test framework.
I'm using psake, msbuild and nUnit to automate my build and testing of an MVC web app, which will be carried out (kindly), by Jenkins, once I have it working.
My build steps work fine, creating two DLL's in the build\bin dir:
MyWebApplication.dll
MyWebApplication.Tests.dll
I'm using nunit-console.exe to run the automated tests as part of the psake build script, pointing it at the newly built MyWebApplication.Test.dll. However, the tests fail due to is saying it could not load file or assembly MyWebApplication.dll, despite it being in the same directory as the test dll file.
How do I go about executing tests using nunit in this scenario?
It's most likely looking for the application .dll in the workspace root, which is the current directory by default in Jenkins. Try changing the current directory to %WORKSPACE%\build\bin before launching the test.
I found the answer to my own question.
I had to compile a debug version of my projects as part of the build script, then run the Nunit console exe against my csproj file for the test project. With this, it executes the tests properly.
So, we have a grails app set up with a Hudson CI build process. We're running unit tests, integration tests, and about to set up Selenium for some functional tests as well.
However, are there any good ways of fully testing a sites links to make sure nothing has broken in a release.
I know there's link checkers in general, but I'd like to have it be a part of the build process, so a build outright fails if something isn't right.
WebTest has a verifyLinks step you could use: http://webtest.canoo.com/webtest/manual/verifyLinks.html
You could install the webtest plugin (it should play nice with Selenium) and just have a single test that checks links.
cheers
Lee
I'm using selenium plugin (http://wiki.hudson-ci.org/display/HUDSON/Seleniumhq+Plugin) with test recorded from both developers and functional people. We start the new instance of the Grails app from the Hudson build with the Postbuild (http://wiki.hudson-ci.org/display/HUDSON/Groovy+Postbuild+Plugin)
What we ended up using was a command line program called linkchecker that we could install by apt-get and we ran from within our build script.