C# – testing internal classes

2015-07-262016-01-30 TPodolak.NET, c#, UnitTest

I am currently involved in writing library which will be used by couple of external teams. In that library we have a quite a lot classes which are only used internally and won’t be a part of public API. The natural way of keeping that code inaccessible for other assemblies is to use internal access modifier. However this makes the code also inaccessible directly for testing. Of course you can still test your internal code through public API but usually this is inconvenient and forces you to write a lot of additional code in test. This is particularly painful for me, because our build process requires 100% test coverage. Fortunately there is an easy way to make internal classes visible for certain assemblies without making them public. All you have to do is to use InternalsVisibleToAttribute and specify assembly name which is allowed to use code with internal access modifier. This attribute is most commonly added to AssemblyInfo.cs file. For example, assuming that my library is in TestingInternalClasses.Lib assembly and my tests are in TestingInternalClasses.Tests I should add

[assembly: InternalsVisibleTo("TestingInternalClasses.Tests")]

1	[assembly: InternalsVisibleTo("TestingInternalClasses.Tests")]

to AssemblyInfo.cs located in TestingInternalClasses.Lib project. However you can also use this attribute in a class definition file – just like that

using System;
using System.IO;
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("TestingInternalClasses.Tests")]

namespace TestingInternalClasses.Lib
{
    internal class VanillaSerializer : ISerializer
    {
        public Stream Serialize(object obj)
        {
            if (obj == null)
                throw new ArgumentNullException(nameof(obj));

            // rest of the code
            // ...
            // ...
        }

        public T Deserialize(Stream stream)
        {
            if (stream == null)
                throw new ArgumentNullException(nameof(stream));

            // rest of the code
            // ...
            // ...
        }
    }
}

using System;

using System.IO;

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo("TestingInternalClasses.Tests")]

namespace TestingInternalClasses.Lib

{

internal class VanillaSerializer : ISerializer

{

public Stream Serialize(object obj)

{

if (obj == null)

throw new ArgumentNullException(nameof(obj));

// rest of the code

// ...

}

public T Deserialize(Stream stream)

{

if (stream == null)

throw new ArgumentNullException(nameof(stream));

// rest of the code

// ...

}

From now on I can easily test internal classes from TestingInternalClasses.Lib project in TestingInternalClasses.Tests. Source code for this post can be found here

WCF – exposing metadata over TCP

2015-06-282016-01-30 TPodolakc#, WCF

I think that everyone who has ever been working with WCF knows that we can enable metadata exchange by adding ServiceMetadataBehavior to App.config file

<behaviors>
     <serviceBehaviors>
       <behavior>
         <serviceMetadata httpGetEnabled="true"></serviceMetadata>
       </behavior>
     </serviceBehaviors>
</behaviors>

</behavior>

</serviceBehaviors>

</behaviors>

Up until yesterday the build in solution works fine for me. However recently I’ve had to expose metadata over TCP protocol. ServiceMetadataBehavior doesn’t have something like TcpGetEnabled property so in order to expose metadata over other protocols (in my case TCP) it is necessary to add custom MEX endpoint.

<system.serviceModel>
    <services>
          <service name="AudioLib.Services.AudioService">
            <endpoint address="AudioService/MEX" binding="mexTcpBinding" contract="IMetadataExchange">
    <!-- application endpoints -->
            <host>
              <baseAddresses>
                <add baseAddress="net.tcp://localhost:8080"></add>
              </baseAddresses>
            </host>
          </endpoint>
        </service>
    </services> 
    <!-- rest of the config -->
</system.serviceModel>

<system.serviceModel>

<host>

</baseAddresses>

</host>

</endpoint>

</service>

</services>

</system.serviceModel>

The endpoint configuration has to have a specific binding – in my case mexTcpBinding (there are of course MEX bindings available for other protocols). What is more, the contract has to be set to IMetadataExchange. The address value is up to us, we can use full blown address as well as leverage base address. At this point if we run service we will get the exception

Even though we added custom endpoint for metadata exchange we still have to use ServiceMetadataBehavior. This time however we can skip httpGetEnabled property

<!-- rest of the config -->
<serviceBehaviors>
        <behavior>
          <serviceMetadata httpgetenabled="true"></serviceMetadata>
        </behavior>
</serviceBehaviors>
<!-- rest of the config -->

</behavior>

</serviceBehaviors>

From now on we can access metadata over TCP

Source code for this post can be found here

Gulp – exluding type definitions files from TypeScript linting

2015-06-132016-01-30 TPodolakGulp, tslint, typescript

I wanted to improve a code quality of my TypeScript project, so I decided to add linting to my gulp build process. My original build task looked pretty straightforward

function buildTypeScript() {
    return gulp.src(['app/**/*.ts','typings/**/*.ts'])
               .pipe(sourcemaps.init())
               .pipe(ts({
                   sortOutput: true,
                   noExternalResolve: true,
                   noEmitOnError: true,
                   target: 'ES5'
               }))
               .pipe(concat(constants.appall))
               .pipe(sourcemaps.write())
               .pipe(gulp.dest(paths.app));
}

function buildTypeScript() {

return gulp.src(['app/**/*.ts','typings/**/*.ts'])

.pipe(sourcemaps.init())

.pipe(ts({

sortOutput: true,

noExternalResolve: true,

noEmitOnError: true,

target: 'ES5'

}))

.pipe(concat(constants.appall))

.pipe(sourcemaps.write())

.pipe(gulp.dest(paths.app));

}

and according to gulp-tslint manual adding linting requires including only two additional lines of code

//..
.pipe(tslint())
.pipe(tslint.report('verbose'));
//..

//..

.pipe(tslint())

.pipe(tslint.report('verbose'));

//..

This works fine until you start using type definitions (d.ts files) from external resources (which is the usual way of combining TypeScript with existing JavaScript libraries). Usually these files have different code styling rules than our own, which means that our build will fail.

There are couple of ways of solving this problem. The obvious one is to split the task into two separate tasks, one for linting and one for building, but in my opinion a much cleaner way is to use gulp-filter. Gulp-filter has an ability to filter the stream on the fly, but what is more interesting it can also restore it to previous unfiltered state. Using these two features we can filter the stream from d.ts files before linting process begins and then restore the stream and pass it to TypeScript compiler. We can do it with two additional lines of code. Improved build script is presented below

function buildTypeScript() {
    // include all typescript files but exclude definitions
    var filter = gulpFilter(['**/*.ts', '!**/*d.ts']);

    return gulp.src(['app/**/*.ts','typings/**/*.ts'])
               .pipe(filter)    // use the filter
               .pipe(tslint())
               .pipe(tslint.report('prose', {
                   emitError: true
               }))
               .pipe(filter.restore()) // clear filter
               .pipe(sourcemaps.init())
               .pipe(ts({
                   sortOutput: true,
                   noExternalResolve: true,
                   noEmitOnError: true,
                   target: 'ES5'
               }))
               .pipe(concat(constants.appall))
               .pipe(sourcemaps.write())
               .pipe(gulp.dest(paths.app));
}

function buildTypeScript() {

// include all typescript files but exclude definitions

var filter = gulpFilter(['**/*.ts', '!**/*d.ts']);

return gulp.src(['app/**/*.ts','typings/**/*.ts'])

.pipe(filter) // use the filter

.pipe(tslint())

.pipe(tslint.report('prose', {

emitError: true

}))

.pipe(filter.restore()) // clear filter

.pipe(sourcemaps.init())

.pipe(ts({

sortOutput: true,

noExternalResolve: true,

noEmitOnError: true,

target: 'ES5'

}))

.pipe(concat(constants.appall))

.pipe(sourcemaps.write())

.pipe(gulp.dest(paths.app));

}

Source code for this post can be found here

C# – dynamic type can be useful

2015-05-162016-01-30 TPodolak.NET 4.0, c#, dynamic

I am not a big fan of dynamic type in C#, however there are certain situations in which it can be handy. Let’s assume that we have following piece of code (which I encounter quite often at my work)

public abstract class Weapon
{
    //some properties
}

public class Gun : Weapon
{
     //some properties
}

// more derived types

var weaponService = new WeaponService();
IList<TransferObjects.Weapon> data = weaponService.GetWeapons();
List<Models.Weapon> weapons = data.Select(WeaponConverter.Convert).ToList();

public abstract class Weapon

{

//some properties

}

public class Gun : Weapon

{

//some properties

}

// more derived types

var weaponService = new WeaponService();

IList<TransferObjects.Weapon> data = weaponService.GetWeapons();

List<Models.Weapon> weapons = data.Select(WeaponConverter.Convert).ToList();

As you can see we have to convert DTO objects into “normal” objects using some kind of converter. This is not a problematic when you can use some auto-mappings libraries (Automapper,FastMapper) however I am not allowed to do that in a company I work for. So the question is how to write WeaponConverter.Convert method in some elegant way. The obvious way (but definitely not elegant) is just to use lots of “if” statements

public static Models.Weapon ConvertOld(TransferObjects.Weapon weapon)
{
    if (weapon == null)
        return null;
        
    if (weapon is TransferObjects.Gun)
        return ConvertInternal((TransferObjects.Gun) weapon);
        
    if (weapon is TransferObjects.Sword)
        return ConvertInternal((TransferObjects.Sword) weapon);
        
    throw new ArgumentException("Unknown weapon", nameof(weapon));
}
// ConvertInternal implementation goes here for every derived type

public static Models.Weapon ConvertOld(TransferObjects.Weapon weapon)

{

if (weapon == null)

return null;

if (weapon is TransferObjects.Gun)

return ConvertInternal((TransferObjects.Gun) weapon);

if (weapon is TransferObjects.Sword)

return ConvertInternal((TransferObjects.Sword) weapon);

throw new ArgumentException("Unknown weapon", nameof(weapon));

}

// ConvertInternal implementation goes here for every derived type

But this is really ugly, much better idea (at least from my point of view) is to leverage dynamic keyword introduced in .NET 4. Thanks to it our Convert method can be reduced to this

public static Models.Weapon Convert(TransferObjects.Weapon weapon)
{
    return weapon != null ? ConvertInternal((dynamic)weapon) : null;
}

// ConvertInternal implementation goes here for every derived type

public static Models.Weapon Convert(TransferObjects.Weapon weapon)

{

return weapon != null ? ConvertInternal((dynamic)weapon) : null;

}

// ConvertInternal implementation goes here for every derived type

Source code for this post can be found here

Nested properties initialization – syntactic sugar

2015-04-182016-01-30 TPodolak.NET, c#

I think most of developers are familiar with the object syntax initializer, which basically allows you to set up values of properties just like that

var webClient = new CustomWebClient
            {
                Settings = new CustomWebClientSettings
                {
                    Encoding = "UTF-8",
                    Method = "POST"
                }
            };

var webClient = new CustomWebClient

{

Settings = new CustomWebClientSettings

{

Encoding = "UTF-8",

Method = "POST"

}

};

In this example the Settings property is assigned with new instance of CustomWebClientSettings class. However for time to time we only want to change particular property of given nested property and leave rest of the object intact. Of course we can write it usual way

// we assume that CustomWebClient initialized Settings property in constructor
var webClient = new CustomWebClient();
webClient.Settings.Encoding = "UTF-8";
webClient.Settings.Method = "POST";

// we assume that CustomWebClient initialized Settings property in constructor

var webClient = new CustomWebClient();

webClient.Settings.Encoding = "UTF-8";

webClient.Settings.Method = "POST";

but there is a much cooler syntax for that. The code above can be rewritten to

var webClient = new CustomWebClient
            {
                 Settings = {Encoding = "UTF-8", Method = "POST"}
            };

var webClient = new CustomWebClient

{

Settings = {Encoding = "UTF-8", Method = "POST"}

};

Note that there is no new keyword in the assignment of Settings property, which means that the Settings object is updated with the values of properties in braces. Of course this syntax can be safely used only if the nested property(in this case Settings) is initialized up front in constructor, otherwise you will get NullReferenceException. Source code for this post can be found here

.NET BLOG

.NET, C# blog

C# – testing internal classes

WCF – exposing metadata over TCP

Gulp – exluding type definitions files from TypeScript linting

C# – dynamic type can be useful

Nested properties initialization – syntactic sugar