sfeldman.NET

Daniel Cazzulino had a very helpful post about how to mock extension methods. The only part I don’t like about this method is the fact you have to make internals visible to the test assembly using an assembly directive:

[assembly: InternalsVisibleTo("Project.Test")]

This is not really bad, since test projects are not deployed. One possible issue with it is assemblies renaming, but that doesn’t happen very often and also relatively easy to track down once things break.

Thanks to Daniel.

One of the recent tests I had, I had to deal with the fact that a dependency object injected into system under test object will be casted to some other interface (known to be implemented) and used. Moq has some documentation on it, but it was a bit misleading. QuickStart wiki showed an example below:

From example it is a bit difficult to see that once foo is marked As<IDisposable>, it can be casted in production code to IDisposable. This is a very helpful feature in Moq.

I am a fan of quick tools that help you sketch out thoughts. These two do exact that type of work.

UML generator

Sequence Diagram generator

While integrating two clients and working on two way authentication, I had to troubleshoot SSL connectivity. Configuration file was my best tool I could use. There are a couple of things I used, and probably there’s a lot more I am not aware of.

ServicePointManager

ServicePointManager helps especially when validating server certificate, by allowing to review what are the errors and make a decision either to proceed or not. This is achieved through ServerCertificateValidationCallback event.

As well, I used configuration file to tweak a few things:

<servicePointManager checkCertificateRevocationList="false"

                     checkCertificateName="false" 

                     expect100Continue="true"/>

Same thing can be done through code (either on ServicePointManager directly, or on request object, ServicePoint property).

System.Diagnostics

Logging is an absolute must when you get an exception, and details of exception are not sufficient enough. Luckily, System.Net (and more nested namespaces) support logging that can be enabled (which reminds me to look under my nose and not to re-invent a wheel). After enabling these logs, I could get detailed trace of SSL communication which helped me a lot. To enable logs:

<system.diagnostics>

    <sources>

      <source name="System.Net" tracemode="includehex" maxdatasize="1024">

        <listeners>

          <add name="System.Net"/>

        </listeners>

      </source>

      <source name="System.Net.Sockets">

        <listeners>

          <add name="System.Net"/>

        </listeners>

      </source>

      <source name="System.Net.Cache">

        <listeners>

          <add name="System.Net"/>

        </listeners>

      </source>

    </sources>

    <switches>

      <add name="System.Net" value="Verbose"/>

      <add name="System.Net.Sockets" value="Verbose"/>

      <add name="System.Net.Cache" value="Verbose"/>

    </switches>

    <sharedListeners>

      <add name="System.Net"

           type="System.Diagnostics.TextWriterTraceListener"

           initializeData="network.log" />

    </sharedListeners>

    <trace autoflush="true"/>

  </system.diagnostics>

Hopefully, this helps someone as it helped me.

Well, I wish there was a way of getting away from SyntaticSugar static class initial point, and be able just to do plain code

Do(() => request.Headers = Headers).If(HeadersExist);

Or even better, this

(request.Headers = Headers).If(HeadersExist);