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.
Jasmine is a very popular JavaScript behavior-driven development (In BDD, you write tests before writing actual code) framework for unit testing JavaScript applications. It provides utilities that can be used to run automated tests for both synchronous and asynchronous code.
Jasmine comes with an inbuilt test runner. Jasmine tests can run browser tests by including a simple SpecRunner. html file or by using it as a command line test runner supported for various languages like Nodejs, Python, Ruby, or (old way) by using Karma, a simple JavaScript test runner tool.
Fortunately there exists the npm package jasmine-node which makes Jasmine available for node. js apps as well. You can give jasmine-node a try by running npm install jasmine-node -g . This will install jasmine-node globally, so we're able to run jasmine-node from the command line.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With