Chutzpah Test Runner for Jasmine JavaScript tests

30. December 2014 16:43

 

I’ve been using Jasmine to write unit tests for JavaScript code and just using the built in browser test runner to the tests. The phase is to incorporate these tests from a command line, build or from within Visual Studio. Running the tests in the browser is pretty straight forward, you just include the necessary Jasmine scripts along with your unit tests and away you go.

image

image

So, nice. We can run our tests and see that they all pass. Except now the c# tests run in Test Explorer in Visual Studio. And to run the JavaScript tests you have open a browser. Chutzpah to the rescue! You can install Chutzpah via NuGet and run it from a command line (which I’m sure will work great with builds, and I’ll test that out when we get a build server set up). There is also a very cool extension to allow you to run the JavaScript tests in the Visual Studio test Explorer!  This is where I ran into some confusing problems. The tests all run and pass in the browser. But running them in Visual Studio they were failing! Some poking around and googling pointed me to the cause. When the tests run in the browser all of the references (angular, etc.) are added in the html page that hosts the tests. When running them in Visual Studio there is no wrapper and nothing including the referenced libraries. Luckily Chutzpah has an answer and Chutzpah.json is it. Add this file and configure your references in it.

image

Now, like magic your Jasmine JavaScript tests show up right along your c# tests in Test Explorer.

image

SSDT With Different User Accounts Per Environment

29. December 2014 09:20

 

I really like SSDT (SQL Server Data Tools). It makes it a breeze to add all of the database code into source control and it generates update scripts to publish changes with ease. One problem I’ve run into is using different user accounts in different environments. We have different domains for development and production so the accounts in the environments are different. Here is an overview of one way to handle this situation.

First I added a security folder with three files to the SSDT project.

image

The Users_DEFAULT.sql should have the build action set to “Build” while the Users_DEV.sql and Users.PRODUCTION.sql should have the build action set to “None”.

Users_DEFAULT.sql can be empty to start while the DEV and PRODUCTION files should contain the necessary TSQL to create the user(s).

-- server login
CREATE LOGIN [csd\wbsmmservice] FROM WINDOWS
GO
	
-- DB login
CREATE USER [wbsmmservice]
	FOR LOGIN [csd\wbsmmservice]     WITH DEFAULT_SCHEMA = [db_owner];
GO
 
 
-- role membership
EXEC  sp_addrolemember @rolename='db_datareader', @membername='wbsmmservice'
GO
EXEC  sp_addrolemember @rolename='db_datawriter', @membername='wbsmmservice'
GO

 

The magic happens during build events. I unloaded the project (right click and unload) and then edited it to add the following.

  <Target Name="BeforeBuild">     <Message Text="Copy files task running for configuration: $(Configuration)" Importance="high" />     <Copy Condition=" '$(Configuration)' == 'PRODUCTION' " SourceFiles="$(ProjectDir)Security\Users_PRODUCTION.sql" DestinationFiles="$(ProjectDir)Security\Users_DEFAULT.sql" OverwriteReadOnlyFiles="true" />     <Copy Condition=" '$(Configuration)' == 'Debug' " SourceFiles="$(ProjectDir)Security\Users_DEV.sql" DestinationFiles="$(ProjectDir)Security\Users_DEFAULT.sql" OverwriteReadOnlyFiles="true" />   </Target>

 

So, now before the build, based on the project/solution configuration, either the DEV or PRODUCTION users file will be copied over the DEFAULT file which will then be used in the compile.

 

About the author

I'm a .NET developer, a husband and a father of three beautiful girls.

Month List