General Ramblings comments edit

Saturday was my seventh in a series of laser hair removal treatments for my face. I had some excellent results from last time and my facial hair is getting pretty noticeably patchy. Especially at the end of the day, I get sort of “five o’clock dirty-face” now since it’s less “shadow” and more sparse. (I went to the dermatologist the other day and forgot to mention I was getting the treatments. He was all, “I don’t remember you mentioning you had really bad acne when you were younger…” It’s pretty patchy.)

The area around my mouth is being a little stubborn, but my chin is the thickest/coarsest hair on my face, so that’s to be expected, and we hadn’t done the MedioStar laser around my lips because that’s apparently the most painful area. To remedy some of that, this time we did MedioStar around the lips (not actually any more or less painful than anywhere else) and went over my chin twice. We also did full face with the DermoFlash IPL. We should be getting some great results this time, though my face burned for a day like a bad sunburn and it hurts to shave because it’s very tender. My patchiness is also far more visible this morning because I have a small amount of bruising, which is not uncommon and generally goes away in four or five days.

Treatment is getting noticeably less painful every time. I’m pretty sure that doing the DermoFlash for a few treatments was the right way to go (for me) because it thinned things out enough that the MedioStar became bearable. They also fairly recently got this cold air machine that blows supercooled air and freezes you right up, making things, again, more bearable. It beats the crap out of putting ice on your face, which doesn’t work.

GeekSpeak comments edit

The Verizon Fios installers just left, and I’ve got my 15mbps up/2mpbs down running in full form. Got everything transferred over to use the Verizon router and Xbox Live, my primary network problem child, seems to be working swimmingly.

15494kbps download/1847kbps
upload

Of course, it didn’t come off without a hitch - the person taking our order mistyped the phone number, so the installers couldn’t really transfer our phone number from Comcast to Verizon because the paperwork didn’t match. So now we have Verizon video and data, and we have both Verizon and Comcast phone. How does that work? Verizon is actually hooked up and running but with the wrong phone number. We’ve had to temporarily keep the Comcast voice service, even if no Comcast junk is hooked up, so we don’t lose our number. It will take a week of futzing around through annoying phone trees and fighting with service people who can’t get off the standard script in order for us to get the number switched. A week to do a two minute job.

Oh, Verizon. I knew you had horrible customer service, and so far, well, I wasn’t wrong.

I like the menus and the TV features a lot better than the Comcast stuff. The UI is far slicker and has a lot of little helpful things in it than the Comcast one did. The net connection seems pretty nice, too, but I can’t really speak to it much since I’ve only written this blog entry and gotten things basically connected. We’ll see how she goes soon.

Oh, and it’s like $50/month cheaper, which doesn’t hurt.

gists, dotnet, testing, build comments edit

Getting TypeMock, NUnit, and NCover to work together in your build script can sometimes be a tricky thing. Getting any one of those things to work individually is easy enough, getting two going is a little tougher, but getting all three together requires a bit of finesse. Add to that the fact that you may run different versions of different products (different NUnit versions, for example) for different source code bases and it gets downright complicated.

The way my product code works, when I check out the codeline I want to work on it comes with all of the dependencies - every third party assembly, every build tool. That includes TypeMock, NUnit, and NCover. That way the build server doesn’t have to have anything installed when it runs a build - it can auto-deploy TypeMock, register NCover, do its thing, and undo all of that when it’s done. (Yes, there are some drawbacks to that - parallel builds are limited when registered versions of profilers change, for example - but we’ve dealt with that sort of thing in other ways.)

On developer workstations, we have TypeMock installed so we can make use of the tracer and other helpful utilities, but on the build server, we auto-deploy TypeMock.

Since TypeMock is a profiler, if you use it in your unit tests, you can’t just run NUnit in the build and have it work - you have to start TypeMock, then run NUnit, then shut TypeMock back down. If you’re using NCover, you have to make sure NCover is registered and linked with TypeMock.

TypeMock comes with some custom build tasks to help you get this working. You will also want to get NCoverExplorer and NCoverExplorer.Extras to get this working well. NCoverExplorer will aggregate coverage logs for you and NCoverExplorer.Extras comes with NCover and NCoverExplorer MSBuild tasks.

The general flow of what needs to happen is this:

  1. Register TypeMock with the system (if it’s not a developer workstation - our devs have it installed).
  2. Register NCover with the system.
  3. Start TypeMock and link it with NCover.
  4. Run NCover and pass it the command line parameters to run your NUnit tests. Tell it which assemblies to profile.
  5. Stop TypeMock.
  6. Unregister NCover with the system.
  7. Use NCoverExplorer to aggregate the coverage reports into a single report.
  8. On error, stop TypeMock and unregister NCover.

Here’s the example:

<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- Register the tasks necessary for running tests and coverage. -->
  <Import Project="Relative\Path\To\TypeMock.NET\TypeMock.MSBuild.Tasks"/>
  <UsingTask
    TaskName="NCover"
    AssemblyFile="Relative\Path\To\NCoverExplorer.Extras\NCoverExplorer.MSBuildTasks.dll"/>
  <UsingTask
    TaskName="NCoverExplorer"
    AssemblyFile="Relative\Path\To\NCoverExplorer.Extras\NCoverExplorer.MSBuildTasks.dll"/>

  <PropertyGroup>
    <!-- Property indicating we're building on a dev machine - build server will set this to false. -->
    <DeveloperBuild>true</DeveloperBuild>
    <!-- Property indicating where build logs will go. -->
    <BuildLogDirectory>Relative\Path\To\Logs</BuildLogDirectory>
  </PropertyGroup>

  <Target Name="test">
    <!-- Register TypeMock only if it's the build server - it'll already be on a developer box. -->
    <TypeMockRegister
      Company="YOUR COMPANY"
      License="YOUR LICENSE"
      AutoDeploy="true"
      Condition="'$(DeveloperBuild)'!='true'"/>

    <!-- Register NCover so it's available for TypeMock. -->
    <Exec Command="regsvr32 /s &quot;Relative\Path\To\NCover\CoverLib.dll&quot;"/>

    <!-- Start TypeMock and link it with NCover. -->
    <TypeMockStart Link="NCover"/>

    <!-- Enumerate the test assemblies you'll be executing with NUnit. -->
    <CreateItem Include="Your\Build\Ouptut\*.Test.dll">
      <Output TaskParameter="Include" ItemName="UnitTestAssemblies"/>
    </CreateItem>

    <!-- Create the folder where unit test and coverage logs will go. -->
    <MakeDir Directories="$(BuildLogDirectory)"/>

    <!-- Run NUnit through NCover so profiling happens. -->
    <!-- Note the use of "batching" so this is equivalent to a "foreach" loop in MSBuild. -->
    <NCover
      ToolPath="Relative\Path\To\NCover\"
      CommandLineExe="Relative\Path\To\NUnit\nunit-console.exe"
      CommandLineArgs="&quot;%(UnitTestAssemblies.FullPath)&quot; /xml=&quot;$(BuildLogDirectory)\%(UnitTestAssemblies.Filename)-results.xml&quot;"
      AssemblyList="MyAssembliesToProfile"
      LogFile="$(BuildLogDirectory)\%(UnitTestAssemblies.Filename)-ncover.log"
      RegisterProfiler="false"
      CoverageFile="$(BuildLogDirectory)\%(UnitTestAssemblies.Filename)-coverage.xml"/>

    <!-- Stop TypeMock and unregister NCover. -->
    <CallTarget Targets="test-finally"/>

    <!-- Get all of the coverage logs and aggregate them with NCoverExplorer. -->
    <CreateItem Include="$(BuildLogDirectory)\*-coverage.xml">
      <Output TaskParameter="Include" ItemName="CoverageReports"/>
    </CreateItem>
    <NCoverExplorer
      ToolPath="Relative\Path\To\NCoverExplorer\"
      ProjectName="YourProjectNameHere"
      ReportType="4"
      Sort="CoveragePercentageAscending"
      Filter="None"
      OutputDir="$(BuildLogDirectory)"
      XmlReportName="CoverageReport.xml"
      HtmlReportName="CoverageReport.html"
      ShowExcluded="True"
      SatisfactoryCoverage="75"
      FailMinimum="True"
      CoverageFiles="@(CoverageReports)"/>

    <!-- In case one of the tests fails, make sure to stop TypeMock and unregister NCover. -->
    <OnError ExecuteTargets="test-finally"/>
  </Target>

  <!-- Stopping TypeMock and unregistering NCover is a separate target because it has to happen -->
  <!-- regardless of success or failure of the unit tests. Like the "finally" in a "try/finally" block. -->
  <Target Name="test-finally">
    <TypeMockStop/>
    <Exec Command="regsvr32 /u /s &quot;Relative\Path\To\NCover\CoverLib.dll&quot;" ContinueOnError="true"/>
  </Target>
</Project>

In the example, notice how the steps for stopping TypeMock and unregistering NCover have been placed in a separate target called “test-finally” since it’s used a lot like a try/finally block. That’s the sort of thing we’re trying to emulate. You’ll also notice that we’re using MSBuild “batching” to run each test assembly through NCover and generate an individual coverage log.

Additional notes:

  • Obviously you’re going to need to change the paths and other placeholder parameters to fit your build.
  • If you’ve got TypeMock installed on dev machines and on the build box, you can skip the TypeMockRegister task and just start/stop TypeMock.
  • If you’ve got NCover installed on dev machines and on the build box, you don’t need to execute “regsvr32” to register/unregister NCover. As long as NCover is registered before you start TypeMock, you’re OK.

dotnet, vs comments edit

I’m playing with the latest release of TypeMock (now “TypeMock Isolator,” as it sounds like they have a suite of products planned beyond their mocking product) and I think my favorite feature is the better debugging support. Sure, you can mock fields now (admittedly, a little scary sounding, but with legitimate applications nonetheless) and they’ve cranked up the performance on it, but how many times have you fired up TestDriven.NET and started your test in the debugger only to get odd behavior because you tried to step into a mocked method?

Now, when you try that, you actually see the method outlined in the debugger so you get a visual cue about what you’re doing:

TypeMock outlines mocked methods in the
debugger.

Oh, and you know how you ran into trouble popping open the watch window, or QuickWatch, and evaluating a mocked call multiple times, causing mock verification problems? No more! The debugger works without hitches. Love it, love it, love it.

This is all in the new TypeMock Isolator 4.2.1 beta. If you get a chance, check it out. Good stuff coming from those TypeMock folks.