binary dreams

This blog post is a copy of information I gathered at the time many moons ago for Moles and may well be inaccurate now but here for reference. I was using Visual Studio 2010 at the time.

Moles best practice

When moling, follow this best practice:

• Use moles as a last resort. Stubs are the preference to mocks. If the object you want to mock has an interface or base class create a stub!
• Always mole your external classes, even constructors! Even empty ones. Do not rely on other code not changing for your tests to pass.
• The preference is for system DLLs to not be moled unless absolutely necessary. You really want them to work as they normally should. Plus you don't want loads of moles for loads of .NET interactions. Moling a system DLL would be required if you must interact with, configuration, files or some other external dependency.
• Observer Locals
  Use booleans when testing for when a property is get or set and when methods are called. For when collections are built, a count should be adequate. Then Assert at the end of the test.
• Use Stubs rather than Moles wherever possible as moles have reportedly worse performance. There is no study to confirm this or even how badly the performance is. It is just in said in the Moles documentation. http://research.microsoft.com/en-us/projects/pex/documentation.aspx
• Consider putting reuseable mock methods into own class with the naming convention as <ClassName>Mock, e.g. DateTimeMock.
• A mock method should ideally handle only one method in the object even if you mock all the other ones. This allows better reuse across the tests as some paths will not require the mocked methods.
• Use our custom the ParameterValidator class (which throws a ParameterValidatorException) to check mole parameters instead of Assertions to keep to the principle of one Assert per test. This will also not confuse anyone when tests break.
  

Moles knowledge base

Mole complains about COM object

Fix

Moling Interop.Vixcom needed the "Embed interop Types" property on the dll set to false to stop Moles generator complaining.

InvalidOperationException: Dynamic operations can only be performed in homogenous AppDomain

Fix

Change a value in the Moles config file:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.Moles.VsHost.x86.exe.config

From:

  <runtime>
     <legacyCasPolicy enabled="true" />
  </runtime>

To:

  <runtime>
     <legacyCasPolicy enabled="false" />
  </runtime>

Information

http://social.msdn.microsoft.com/Forums/en/pex/thread/0a931fc1-9049-482a-bf2d-5499ccf65b82

TFS build shows a Moles warning

Example

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (1360): Could not resolve this reference. Could not locate the assembly "mscorlib.Moles, Version=4.0.0.0, Culture=neutral, PublicKeyToken=0ae41878053f6703, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

Fix

• Unload the test roject. Right-click on the unloaded project and select "Edit ... proj"
• Replace this reference
  <Reference Include="mscorlib.Moles.dll, Version=4.0.0.0, Culture=neutral, 
  PublicKeyToken=0ae41878053f6703, processorArchitecture=MSIL" />  

  <Reference Include="mscorlib.Moles.dll, Version=4.0.0.0, Culture=neutral, PublicKeyToken=0ae41878053f6703, processorArchitecture=MSIL" />
• With this
  
  1. <Reference Condition="Exists('..\..\MolesAssemblies\mscorlib.Moles.dll')" Include="mscorlib.Moles.dll">   
  2.   <SpecificVersion>False</SpecificVersion>   
  3.   <HintPath>..\..\MolesAssemblies\mscorlib.Moles.dll</HintPath>  
  4. </Reference>  

  <Reference Condition="Exists('..\..\MolesAssemblies\mscorlib.Moles.dll')" Include="mscorlib.Moles.dll"> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>..\..\MolesAssemblies\mscorlib.Moles.dll</HintPath>
  </Reference>
• Note: The moles hint path assumes the test project is referencing from a "bin\Debug" folder.
• Note: If you get local compile warnings of "The referenced component 'mscorlib.Moles' could not be
  found." then ignore it.
  

In my previous company I needed a set of instructions for anyone to use when installing an Experian certificate on a server. This certificate was required when calling the Experian servers from a WCF service hosted in IIS. These instructions can be reused for other similar scenarios.

Now we need to add the certificate.

1. Click Start > Run...
2. Type MMC and click OK
3. Click Yes and the Management Console will open.
4. Select File > Add Remove Snap-in.
5. Double-click on Certificates.
6. Select Computer Account and click Next then Finish.
7. Click OK.
8. Expand the Certificates (Local Computer).
9. Right-click on Personal, select All Tasks and Import.
10. Browse to the location of the certificate you are using. You may need to change the type of files to "All files".
11. Click OK.
12. Click Next.
13. Enter the password (if required). the UAT certificate password is "password".
14. Click Next and Finish.
15. Click on the Personal > Certificates folder.
16. Drag and drop the Intermediate certificate to the Intermediate Certification Authorities > Certificates folder.
17. Drag and drop the Trusted Root CA to the Trusted Root Certification Authorities > Certificates folder.
18. Now we need to make sure the Network Service has the permission to use the certificate.
19. Still in MMC, expand the Personal > Certificates folder.
20. Right-click on the certificate supplied and select All Tasks > Manage Private Keys...
21. Click Add and in the object names text box enter NETWORK SERVICE.
22. Click OK and OK again.
23. Close the MMC. No need to save console settings.

One more thing. I highly recommend you use the Smoke Tester to do some basic tests on the certificate after installation.

I need to write down what I need to install whenever I have to reinstall everything onto a Dev PC. Our company UK Dev PC build PLUS:

• Visual Studio 2010
• Visual Studio 2012 + update 4
• Visual Studio 2012 Extension - Nuget.PackageNPublish
• Visual Studio 2012 Extension - NCrunch (if I am using it)
• TFS 2010 Power tools (September 2011)
• DevExpress 13.x
• WiX 3.6 
• XPath Builder
• Connection String Manager
• WCFStorm 2.5
• Virtual Clone Drive
• Telerik JustDecompile
• VMWare vSphere Client
• KDiff 3

Internet Explorer

Enable the Favourites Bar and add everything required to it.

TFS Workspaces

Remember: If you just permanently moved to a new PC then you might need to delete your old PC TFS workspace.

Remove a Workspace

Power saving settings

Change Hard disk to turn off after 4 hours.

Change Power saving to not turn off Network Card so I can remote login quickly.

Hopefully this can be of use to other people as well.

In June 2014 my ex-colleague open sourced a smoke test tool that we began using at our previous company. It was originally created by another colleague to be used for deployment testing. You could check a WCF service responds as expected, a database connection succeeds or the AppSettings in a configuration file are as expected.

I had a problem recently where I needed to confirm my WiX installer had successfully set the website Windows Authentication providers to "NTLM, Negotiate" - in that order. To do this I needed to create a brand new smoke test - the XMLDocumentTest.

The idea of this smoke test is to run an XPath query over an XML document. In my test I needed to check the IIS applicationHost.config file. Here is a sample of it's contents:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<location path="Fake Application">
<system.webServer>
<security>
<authentication>
<digestAuthentication enabled="false" />
<basicAuthentication enabled="false" />
<windowsAuthentication enabled="true">
<providers>
<clear />
<clear />
<add value="NTLM" />
<add value="Negotiate" />
</providers>
</windowsAuthentication>
</authentication>
</security>
</system.webServer>
</location>
</configuration>

Then if you run this XPath query over it.

/configuration/location[@path='Fake Application']/system.webServer/
security/authentication/windowsAuthentication/providers/add

You should get this result.

<add value="NTLM" />
<add value="Negotiate" />

I highly recommend the XPathBuilder application to work out your query for the smoke test.

The smoke test will look like this. Make sure the XPathQuery and ExpectedOutput elements have no line breaks, otherwise the test will not succeed.

<?xml version="1.0" encoding="utf-16"?>
<ConfigurationTestSuite xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Name>XMLDocumentTests</Name>
<Description>This a sample smoke test of the XMLDocumentTest</Description>
<Tests>
<Test xsi:type="XMLDocumentTest">
<TestName>Check Windows Auth providers</TestName>
<Path>C:\location\of\configfile\</Path>
<Filename>applicationHost.config</Filename>
<XPathQuery>/configuration/location[@path='Fake Application']/system.webServer/
security/authentication/windowsAuthentication/providers/add</XPathQuery>
<ExpectedOutput><add value="NTLM" /><add value="Negotiate" /></ExpectedOutput>
</Test>
</Tests>
</ConfigurationTestSuite>

To use the tool you can run this command. Make sure the InstallationSmokeTest.exe and smoke test file are together when running it.

InstallationSmokeTest.exe Run FakeSmokeTest.xml

At the time of posting the new test is only in the Main branch. You can download the latest Smoke Tester from CodePlex and read more information on the smoke tester here.

If ever you have the message that the login failed it may be because of an orphaned user.

Run this to check what orphaned users you have.

EXEC sp_change_users_login 'REPORT'

Then run this to fix it. Where ‘LoginName’ is the login and then the user it is attached to.

EXEC sp_change_users_login'UPDATE_ONE','LoginName','LoginName'

From this website http://mcpmag.com/articles/2011/02/17/fixing-sql-server-2008-database-orphans.aspx