Modern Development needs Unit Tests to enable the trust in code even after large changes. SharePoint is traditionaly bad to unittests as the server side object model is very bad to mock (no interfaces, komplex dependencies between objects, only on sharepoint server, …) The newer client side api hasn’t gotten much love on this either. But I want to try to use at least some unittesting in JavaScript. So I decided to start embedding some unittest frameworks into new SharePoint Apps to find which works for me in this context.

If you create a new app in the web IDE (Napa), you get several files. The difficult part is, where to place the code. After some experiments I found a way which works for me, at least for a start. The best place (or the place which worked) is to put script, css and qunit div in the default aspx. qUnit is referenced from the scripts directory but you can of course use the CDN Url. Unittests are located in scripts/test.js. When this will grow, it will be refactored to multiple files, but not unless needed.

<%-- The markup and script in the following Content element will be placed in the <head> of the page --%>
<asp:Content ContentPlaceHolderId="PlaceHolderAdditionalPageHead" runat="server">
<script src="https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.6.2.min.js" type="text/javascript"></script>
<!-- Add your CSS styles to the following file -->
<link rel="Stylesheet" type="text/css" href="../Content/App.css" />
<!-- qunit -->
<script type="text/javascript" src="../Scripts/qunit-1.10.0.js"></script>
<link rel="stylesheet" href="../Content/qunit-1.10.0.css">
<!-- Add your JavaScript to the following file -->
<script type="text/javascript" src="../Scripts/App.js"></script>
<script type="text/javascript" src="../Scripts/tests.js"></script>
</asp:Content>
<%-- The markup and script in the following Content element will be placed in the <body> of the page --%>
<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
<div>
<p id="message">
<!-- The following content will be replaced with the user name when you run the app - see App.js -->
initializing...
</p>
</div>
<h2>Unit Tests</h2>
<div id="qunit"></div>
<div id="qunit-fixture"></div>
</asp:Content>

A co-worker asked the other day about a communication between different powershell scripts. First solution was using Mutex but it showed pretty fast that Mutex and Semaphore does only work in Powershell if you start with the –STA switch. By default Powershell uses a Multithreaded Apartment with each command running in its own thread. So when the simples method failed I looked for other means

Named Pipes to the Rescue

Named Pipes are not supported natively by Powershell (as far as I know). But as you can use any .Net Classes in Powershell thats not a Problem. You only need to load the System.Core Assembly (from .Net 3.5) via either

add-Type -assembly "System.Core" (in PS V2)

or old fashioned via

[reflection.Assembly]::LoadWithPartialName("system.core")

Some are telling you to load with explicit version but IMHO this only
ties you to a certain combination of Powershell and .Net. Usualy newer versions of .Net ensures backwards compability anyway.

On the client side you are writing to the pipe. As long as you don’t send the exit command you can connect from different clientscripts.

Naming the Pipe

Named Pipes must have uniq names per System so you better use something like \\.\pipe\company.tld.app. While the server side is bound to use localhost ‘.’ the client can use a remote connection with the \\servername\pipe\… syntax. (If the policies and firewall settings permit it).

I might revisit it and bring it to a proper module form but for the moment it is enough. Stay alert as this is not tested in production qualitiy scripts there might be a lot of caveats. Don’t say I didn’t told you.