Is it practical/possible to separate jasmine tests into a separate visual studio project?
I am just getting started with angular, and am trying to write my tests before I start on the actual angular implementation. I will be writing my project in Visual Studio 2012 with the Chutzpah test runner, see this video. Currently, I am trying to figure out how to organize my folder structure. I know about angular-seed and yeoman, but those are ill suited to starting a .net project.
I am assuming that since unit tests in Visual Studio are usually separated into a separate test project, by convention, the jasmine tests should, too.
However, for java script, there are no project dlls to reference, so separating the tests out into a different project would require a lot of copy and pasting, I think.
You can do this with no copy/pasting. In your Jasmine tests you can add a /// <reference comment which posts to your source files (or the directory containing them). For example given this sturcture
/ProjectA /scripts
code1.js
code2.js
/TestProjectB test1.js
You can add this line at the top of your test1.js file to reference all your code files:
/// <reference path="../scripts" />
Traditionally, I've always kept unit tests in separate assemblies.
I've read both sides of the argument and prefer not to ship code that isn't production code, or to have additional deployment steps to remove tests from production code.
In order to reference javascript in my Web.Client.Tests assembly, for example, I use a post-build event to copy the files into the test project. For this I use robocopy - it looks something like this:
robocopy "$(ProjectDir)app" "$(SolutionDir)Tests\Presentation\Web.Client.Tests\app" /E /COPY:D /IS
robocopy "$(ProjectDir)Scripts" "$(SolutionDir)Tests\Presentation\Web.Client.Tests\Scripts" /E /COPY:D /IS
if errorlevel 1 GOTO :eof
The main con with this approach is that you have to build the project each time, like you'd have to with your C# code, to update the test project before running the tests.
Think you should use default folder structure as recomended by jasmine
here is a link showing default structure of jasmine
Related
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'm trying to get TFS to run my unit tests.
The name of the project assembly is Users.SystemTests.dll. It's located in ~/source/Users.SystemTests/bin/debug. The solution file is located in ~/source/Users.sln.
I've included the Nunit.VisualStudio.TestAdapter nuget package the in test assembly project.
The results of the build shows that the tests don't run.
What am I missing? They run fine locally via the Resharper test runner and I can also use nunit-console-x86.exe to run them.
Does this have something to do with the fact that I'm building a solution file? Maybe it's the output location being "AsConfigured?"
Ok, so I tracked this down on my own. It was twofold. The first problem was the the TestAdapter was not being output to the bin directory. The other piece was the Output Location. Setting copy local and then Output Location SingleFolder fixed the issue.
I do believe this is a bug in the tfs build. It works when you use SingleFolder or PerProject, but not AsConfigured. In the latter case the test runner don't find the testassemblies, and this is the same for both NUnit and MSTest, so it is not adapter specific.
The diagnostics log says:
Run VS Test Runner00:00:00
There were no matches for the search pattern C:\a\bin\**\*test*.dll
There were no matches for the search pattern C:\a\bin\**\*test*.appx
I am using Chutzpah to run our Jasmine tests.
I have added the Chutzpah dlls to the solution and updated the build to run *.js tests.
The project structure is as follows:
MyApp.Web
Scripts
App
Home
DateControl.js
MyApp.Web.Tests
Scripts
Jasmine
lib
Chutzpah (dlls)
Spec
App
Home
DateControlSpecs.js
The Jasmine test file uses a reference tag to reference the file to be tested
/// <reference path="../../../../../../App.web/scripts/app/home/datecontrol.js" />
The Jasmine tests are run however I get the following error:
ReferenceError: Can't find variable: dateControl in file
dateControl is the object under test.
If I copy the code to be tested into the Jasmine test file then the tests pass.
The jasmine tests with the reference tag pass using the Chutzpah Test Adapter in Test Explorer in Visual Studio 2013.
I have no idea why this is not working.
Update
#jessehouwing's answer pointed out the route of the issue for me.
The build folder on the build server has the following structure
bin
_PublishedWebsites
src
The jasmine test scripts and libraries are copied to bin whereas the script files under test are copied to both the src directory and the _publishedwebsite directory.
I am looking for an easy to manage solution so that any future devs do not need to know they need to link any new scripts into the test project.
Solution I can live with for now
For both the jasmine test files and the files under test I added "Always copy" in properties as per the Chutzpah documentation. I didn't realise that the files under test were actually being copied to the builds bin folder along with the jasmine test files.
So on the build server I ended up with the following struacture
bin
scripts
app
* application js files
specs
* jasmine test files
In my jasmine test file I add two references:
The first to the Visual Studio directory sturcture of the file to be tested
The second to the build bin folder structure
Hack 1
I can get it to work by adding another reference to my jasmine test file which uses the structure of the build directory and not the solution directory structure but again this is open to error as the path may be typed in incorrectly.
The second reference below will allow the tests to run in both VS Test Explorer and TFS Build
/// <reference path="../../../../../../App.Web/scripts/app/home/datecontrol.js" />
/// <reference path="../../../../../_PublishedWebsites\App.Web/scripts/app/home/datecontrol.js" />
Hack 2
By adding an xcopy command to the post-build build event of the project I can copy the files to be tested into the same location as the jasmine test files.
This is most likely caused by the fact that Team Build separates the Sources and Binaries folders and enforces a different output structure in the Binaries folder as well. This means your files are not in the place you expect them to be.
To ensure the test runner can always find your references you must use the "Add as Link" option in Visual Studio and set their build action to "Copy Always" so that they're copied to the test directory upon test execution.
Plus, you might need to enable "Deployment" in the Test configuration in your Build Definition, as outlined here.
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.
I’m working with a VS2010 solution that has multiple projects (normal assemblies, an ASP.NET MVC project, a Windows Azure project, and a SQL project). I am trying to figure out how to set up a TFS build definition to deploy both the Windows Azure project and the SQL project.
I know how to do a Windows Azure deployment, and have a custom build task in the Windows Azure project file (.ccproj) that does the deployment. I can easily create a build definition that runs against the .ccproj file, passing in some MSBuild command line arguments as parameters, and works as expected.
I can create another build definition that runs against the SQL project (.sqlproj) file, passing to MSBuild the build targets and parameters needed to build and publish the SQL project. That works as expected.
As two distinct build definitions what I have works. Easy enough.
What I have yet to figure out is how to combine these two build definitions into one. Is that even possible (without a lot of work)? Ideally I’d be able to kick off a new build that will build the projects and deploy them both (just as they do as separate build definitions) as part of a single unit of work.
I have tried using the solution file as the item to build, and specifying the build targets as /t:<project>:<target>;<project>:<target>. But, apparently that syntax only works for targets in the base set and not any custom targets or those imported by other .targets files (or so that’s my understanding).
What is the best (simplest) way to accomplish what I’m looking to do?
Sure you can totally do this! Basically, you need to have a target in each project with the same name. Then you change the DependsOn list for each to include the project specific list of targets. Example:
Project 1:
<Target Name="MyBuild" DependsOnTargets="AzureTarget1,AzureTarget2" />
Project 2:
<Target Name="MyBuild" DependsOnTargets="SQLTarget1,SQLTarget2" />
Then you can tell the build definition to build the MyBuild target on each and it should invoke the appropriate DependsOn targets.
This is a very simple example of how to do this, but you can make this much more robust if you also use MSBuild Traversal projects and an MSBuild traversal task much like the method described in the following article under the "Building Large Source Trees" section:
http://msdn.microsoft.com/en-us/magazine/dd483291.aspx#id0100082