Casting reflected types – What I learnt

For my Translation Tester I originally wanted a user to be able to add a mapping between two properties of different types, so for example they could say that a property of type Int16 would be directly assigned to a property of type Int32 by the translator. This turned out to be real tricky to get working, and after much analysis I’m not sure it should even be done as part of a ’simple mapping’.

The problem is that the types of the parameters are found using reflection, so you then need ways to tell whether there are any commonly supported ways to convert one type to another, and then a way to actually do the conversion to verify that the mapping was fulfilled.

To expand the problem let’s list some of the possible scenarios:

• Primitive type that can be implicitly cast to another primitive type (e.g. Int16 assigned to Int32)
• Primitive type that can explicitly cast to another primitive type (e.g. Int32 to Int16)
• Primitive/Struct/Class to Primitive/Struct/Class where an implicit cast operator has been added
• Primitive/Struct/Class to Primitive/Struct/Class where an explicit cast operator has been added

This gets pretty confusing, particularly with all the permutations for the last two.

IConvertible/Convert.ChangeType

When dealing solely with the primitive types there is an interface IConvertible that they all support, that allows conversion between the primitive types. The Convert.ChangeType() method simply provides a nice wrapper around the IConvertible interface. One problem here is that for several of the primitive types they have the whole interface, but individual conversions will always fail at run-time (e.g. decimal to DateTime).

So this facility can be used for primitive types at comparison time, but to determine whether a simple mapping should be allowed you’d have to actually attempt a dummy conversion, using something like Activator.CreateInstance().

TypeDescriptor.getConverter

I posted a question on StackOverflow.com, one of the answers suggested I look into TypeConverters. From what I can see the built in TypeConverters are focussed on converting from and to strings. This facility could be used to provide Converters for primitive types and even allow users to add converters for custom types. But this all seems rather heavy.

Dynamic Cast

This post contains an interesting implementation for dynamic casting based on looking for implicit (and if necessary explicit) cast operator methods on the reflected types and using them to perform a cast. One problem is that the primitive types don’t use cast operators to cast between themselves, rather they use the IConvertible interface. So this wouldn’t work for primitive-to-primitive conversions.

What I’ve done

This all seemed to be getting really confusing, so what I’ve done at the moment is only allow simple mappings to be added where the types are identical. This makes the code a lot easier, and also removes any magic being hidden from the user; if they want to map a property to a property of another type they can specify this using a complex mapping (predicate).

What I might do

Having written all this down I think it might be possible to do what I originally intended. using the following steps to add a mapping (confirm that it’s possible):

• If both types are primitives – Consult a local dictionary of valid mappings
• else use the Dynamic Cast method to determine if there is a cast operator specified
• If no cast operator specified see if there is a custom converter (perhaps based on TypeConverter).

Then the following steps to verify the mapping

• if both types are primitives use Convert.ChangeType() to convert the from type to the to type.
• else use the cast operator or custom converter specified.

Another thought I’ve had is that you might want to limit the allowed conversions to just implicit conversions (where you wont lose precision/data), this could be achieved by splitting the primitive mappings into 2 lists, and separating the dynamic cast into 2 checks.

Extending unit testing frameworks with the Translation Tester

While I’ve been working on my TranslationTester project, I’ve been wondering whether the tool should either be a stand-along tool, or whether it would make sense to contribute it to one of the many unit testing frameworks out there (NUnit, MbUnit, xUnit). I don’t think it’s ‘frameworkey’ enough to contribute to the main products, but perhaps it could be contributed as some sort of extension/plugin etc.

My current thinking is that I’ll create it framework-independent, and then maybe write simple wrapper classes that allow it to be used in each framework in a more integrated fashion, e.g. Define a base TestFixture class for NUnit.

Rationalising mocked dependencies using concrete types

This really is amazingly obvious and simple, but for some reason it never occurred to me.

The situation I’ve been getting myself into is that I have Business Logic actions that do a very discrete bit of logic, these will have dependencies on data access repositories as well as other business logic actions (potentially). I was happily using interfaces for the data access dependencies and then continued to use them for business logic dependencies, this lead to a bit of a mass of interfaces, and I also ended up with tests that mocked all these dependencies, resulting in missing lots of problems that occur in the interaction between business logic actions.

What I really want is that all data access dependencies can be replaced by mocks, but the ‘real’ instances of all the business logic actions are used. This seemed hard to achieve as we are not using an IOC container for our dependency injection (What a pain!) so use a default constructor for each class that just provides real implementations. So if we use a real instance of the business logic dependency we either have to know about it’s dependencies (resulting in massive constructors for all possible dependencies in the object graph).

The solution I hit upon today seems kind of obvious now (and of course is completely irrelevant if you have an IOC Container). Specify all data access dependcies by interface so they can be mocked out. Specify all business logic dependencies as concrete dependencies (still in the constructor). Use default constructors to use default instances of all the dependencies. In tests create all business logic objects for the required object graph using dependency injection, use mocks for data access dependencies and real instances for business logic actions.

Demo class diagram

public class Class1 { private IDataAccess1 dataAccess1Dependency; private Class2 class2Dependency; public Class1() : this(new DataAccess1(), new Class2()) { } public Class1(IDataAccess1 dataAccess1, Class2 class2) { this.dataAccess1Dependency = dataAccess1; this.class2Dependency = class2; } public int MethodToTest() { return class2Dependency.Method() + dataAccess1Dependency.GetInt(); } }

public class Class2 { private IDataAccess2 dataAccess2Dependency; public Class2() : this(new DataAccess2()) { } public Class2(IDataAccess2 dataAccess2) { this.dataAccess2Dependency = dataAccess2; } public int Method() { return dataAccess2Dependency.GetInt(); } }

/// <summary> ///A test for MethodToTest ///</summary> [TestMethod()] public void MethodToTestTest() { MockRepository mocks = new MockRepository(); IDataAccess1 mockDA1 = mocks.DynamicMock<IDataAccess1>(); IDataAccess2 mockDA2 = mocks.DynamicMock<IDataAccess2>(); Class2 class2Instance = new Class2(mockDA2); Class1 target = new Class1(mockDA1, class2Instance); using (mocks.Record()) { Expect.Call(mockDA1.GetInt()).Return(5); Expect.Call(mockDA2.GetInt()).Return(6); } using (mocks.Playback()) { int expected = 11;//5+6 int actual = target.MethodToTest(); Assert.AreEqual(expected, actual); } }

Translation Tester, part 3 – Requirements

In the 3rd part of the Translation Tester series I intend to come up with some initial requirements for the product. This will then be used to create a product backlog and drive development via ‘Test Driven Development’. I’m going to try and express the requirements as ‘user stories‘.

The users

First a quick introduction to the users; I realise that I should probably have some real users providing my user stories, and in due time I hope to add to my initial user stories with real end-user stories.

The Traditional Developer is a developer who writes code and then writes some unit tests afterwards to test parts of their code.

The Test Driven Developer uses tests to drive the design and development of their code

The term Developer will be used to refer to all developers.

The Development Manager manages a team of potentially changing developers over a period of times, potentially on several projects.

The Build Engineer manages and monitors a product’s automated build.

The Stories

So without further ado lets start writing some stories, although they’ll probably go from simple to complex no prioritisation or ordering is intended at this stage.

As a Developer
I want to test my translator classes
So that I have confidence that they work

As a Developer
I want to specify that a property should not be translated
So that I can have minimal classes

As a Developer
I want to be able to clearly see properties that were excluded from the translation
So that as requirements change I can easily identify the changes to be made and bug fixing should be easier

As a Developer
I want to know when my code change has broken another area of the code
So that I can have confidence in making changes without the risk of regression

As a Developer
I want to reduce the amount of ‘boilerplate’ code for testing translators
So that I can work more efficiently

As a Developer
I want to be able to specify complex translations where necessary
So that as much as possible of the translation can be tested

As a Developer
I want the tests for my translator to specify the desired output, not how the output is achieved
So that my tests are more robust, and don’t just duplicate the production code

As a Developer
I want each test to test one aspect of the translator
So that a failed test clearly indicates the reason for the failure and other failures are not hidden

As a Developer
I want to exercise the translator with a wide range of inputs
So that I can test the translator handles a wide range of inputs correctly

As a Developer
I want to be able to use a mocking framework to test that a call was made as part of the translation
So that I can test parts of the translation that do not easily allow for state based testing

As a Developer
I do not want to be forced to use a specific mocking framework
So that I can work the way I (and my team) work.

As a Development Managers
I do not want to be tied to any other dependencies (such as on a specific unit testing framework)
So that I can choose what tools the team will use and change my mind in the future

As a Build Engineer
I want to automate running of the translation tests
So that I can be notified of a failure without any manual intervention

As a Test Driven Developer
I want to be able to start from a small skeleton translator and test class
So that I can get quick feedback on my development

As a Test Driven Developer
I want each small test to indicate the work that must be done in the translator to make the test pass
So that I can use the tests to drive my development.

Translation Tester, part 1 – The problem

Introduction

This post is the 1st in what may become a series of posts detailing the development of a test support tool for testing ‘Translators’. I’m planning on blogging the development of this tool for a few reasons. One reason is to try and gauge if there is any interest in the tool (may impact whether I bother to continue development and maybe even extending it to a releasable open source product). Another reason is so that if anyone out there thinks there is a tool out there that already does this they can tell me and save me a whole load of effort

Some useful information before I state the problem…

It may be worth me starting by explaining what I mean by a ‘Translator’; When you have a layered architecture in a software product/suite you often have de-coupled representations of concepts for each layer rather than having a common set of representations for all the layers. This means that whenever you cross a layer boundary you need to convert from one representaion of the data/concepts to another, the class that does this conversion I would call a Translator.

Entity Translator diagram

Modern software development seems to be more and more layered, and with some concepts like Domain Driven Design (DDD) and The Onion Architecture advocating decoupling different parts (or layers) of an application from each other, it seems to be more and more prevalent.

The problem

The problem I’ve found with Translator classes is that they can be pretty difficult to unit test reliably, flexibly and effectively.

1. Unit tests often seem to over-specify the behaviour and are pretty much just directly duplicating the translator code.
2. Writing unit tests for translators can be long and laborious with seemingly little benefit, it’s almost mindless coding. However a lot of bugs seem to be due to translators, so they obviously do need to be tested.
3. When a new property/field is added to one of the types being translated from/to the test will often continue to pass, and there will be no indication that the translator is not attempting to translate the field.
4. An untranslated property often doesn’t cause an immediate problem (compilation failure, unit test failure, immediate run-time failure). Rather the missing data will show up some time later as a hard to diagnose bug.
5. When a bug is identified it can often be traced back to a translator not mapping a field, when you have several layers each with each layer boundary having a translator there can be a lot of places to look!
6. Over time translator tests go out of date, and not even due to any changes of the class being tested changing (the translator), rather that one of the types being translated has changed.

Strictly mocked operations rather than strictly mocked interfaces?

Recently I’ve been planning to contribute to the rhino mocks wiki. One of the topics I thought I would write about is when I would use the different types of mock (CreateMock, DynamicMock, Stub etc). To this end I was trying to think why you would want to use CreateMock; that is a mock that enforces strict replay semantics.

When would you want strict replay?

- When you don’t want your target (System Under Test) to make calls other than those that you have expressly defined. Usually I don’t think you care, but sometimes these calls will be ‘expensive’, in the sense that they do something like make a web service call, and so we don’t want to make the call un-necessarily. Or that they cause a change of state, that is where making the call would result in incorrect behaviour of the system (e.g. A method that called CreditCardService.TakePayment() twice instead of once would probably be a ‘bad thing’). In these examples what I am really bothered about is that certain mocked operations obey strict replay semantics, rather than the whole interface.

How to use strictly mocked operations in Rhino Mocks

So if we want a mocked operation that obeys strict replay semantics we can simply use a DynamicMock and set individual operations to be restricted using Repeat.Never() or Repeat.Times(), I would also argue that this will result in much more expressive tests as you are expressly saying what operations should not be called rather than hiding this in the type of mock created.

I am not saying that a strictly mocked interface is completely un-necessary, sometimes you know that an interface is full of methods we don’t want to call (such as a web service client), and we don’t want to have to enumerate every method. Rather you should probably think about what you want to restrict calls to.

Suggested rule of thumb:

• If the interface is to an ‘expensive’ class to call use a strictly mocked interface.
• If the interface contains methods which result in a change of state then certain methods should be strictly mocked.

Upgrading CAB solution to Visual Studio 2008 and making all the tests pass

For one reason or another we’ve recently upgraded the Microsoft Composite Application Block solution to a Visual Studioo 2008 solution. The conversion appeared to succeed, but when we tried to run the unit tests we had lots of failures. I then went through trying to figure out whether these failures represented functional failings in the CAB built from this source (this would be a ‘bad thing’) Or whether they were issues with the tests.

This post details the steps required to fix all the unit tests

Expected Exception Attribute not working

The first problem seemed to be that any test that had an ExpectedException attribute failed, with the reason being that an exception was thrown… hang on… isn’t this what we wanted? Seems that the attribute wasn’t being recognised by the unit test framework (MSTest). The cause being that the test projects had a reference to the wrong version of the MSTest dll. So although Visual Studio was using MSTest 2008 to run the tests it was looking for attribute definitions in another version of the dll… Seems like this should have been picked up by the conversion wizard. Anyhow, it’s a simple fix, remove all the references to Microsoft.VisualStudio.QualityTools.UnitTestFramework and add them again making sure you get the V9.0 dlls.

AppDomain Base Directory has changed

The next issue I resolved was a little more tricky. Several tests were failing in the FileStatePersistenceService, and after some digging it looked like it was because there were lots of relative addresses being used for generating files, the files were therefore being created in the AppDomain.CurrentDomain.BaseDirectory, but then being looked for in the Environment.CurrentDirectory. In MSTest 2005 these happened to be the same location. Due to a change in MSTest 2008 they are no longer the same. This page explained the problem and a fix, which simply involves adding a line to run before the test that changes the BaseDirectory.

AppDomain.CurrentDomain.SetData(“APPBASE”, Environment.CurrentDirectory);

Namespace changes on embedded resources

The next issue was one found in ReflectionModuleEnumeratorFixture and ModuleLoaderServiceFixture. Both of these test fixtures involved dynamically compiling classes from embedded resources. (I can’t help but wonder if this is overkill for a unit test). Anyway, this was kind of hard to diagnose, the only problem being that a stream was being created from the ExecutingAssembly().GetManifestResourceStream(input), and this was returning null. After debugging and looking at what was returned from GetManifestResourceNames() I noticed that there was a mismatch in the names being looked for and those used for the embedded resources. To fix the tests I changed all the calls to compile files in the constructor to reference the correct names. This involved replacing Microsoft.Practices.CompositeUI.Tests.Mocks.Src with Microsoft.Practices.CompositeUI.Tests.Instrumentation.Mocks.Src

Last Test – LoadModuleReferencingMissingAssembly

The final test to outsmart me was the LoadModuleReferencingMissingAssembly test, this test attempts to load a module that calls out to another module that has not been included  in the ModuleInfo. An exception should be thrown when the call is made to Module.load(). However in 2008 no such exception is thrown, with execution proceeding as normal. In 2005 a FileNotFound exception is thrown saying that it can’t find the referencedAssembly. In both cases the dll is present in the output directory. At the time of writing I have been unable to fix this test, I wonder if the issue is related to the AppDomain changes, but the proposed fix doesn’t seem to work.

Any suggestions more than welcome!

TALC Driven Development

Recently I’ve been reading several blog posts about the effectiveness of Test Driven Development. Of particular interest is Jacob Proffit’s TDD or POUT

It seems to me that there is Plain Old Unit Testing, which I would argue implies “test at the end” unit testing at one of the spectrum, and then pure TDD at the other end. I see myself being near the TDD side, but not all the way; in fact I would categorise my approach as “Test After Little Code” Driven Development, or Pragmatic Unit Testing. What I tend to do is write a little bit of code first then write a test that exercises the code. From that point I’ll do one of two things, either write another little bit code and then test it, or sometimes write another test which deals with a slightly different case and then write the code to make it pass. Often different situations seem to lend themselves to a different approach.

I’m not sure exactly how Jacob does POUTing, but I’d imagine he doesn’t leave all the unit testing to the end. I think this is the real ‘enemy’ of unit testing, as by the end you are facing all the issues that TDD addresses such as code that isn’t testable, or no time left to test. These issues aren’t only solved by TDD, they can also be solved by incremental unit testing.

Missing ‘Test’ ‘Edit’ or ‘Properties’ buttons in Fitnesse

Today I’ve been trying to get my head around Fitnesse, so far it seems pretty cool. One thing that confused me, that I found a neat solution for, is that the help often says press the test button on the page, but there was no test button…

So to get a test button you can click on the Properties button and tick the Test checkbox. That’s great, but what if there is no Properties button either? The same problem sometime happens when the ‘Edit’ button is missing.

The solution relies on the fact that all the buttons do is link back to the same page with a Get query string so to test a page you can simply add ?test to the URL (e.g. http://localhost/page?test). This works but can get a bit tiresome, so you should use the properties page to add the required buttons to the page, so if the Properties button is missing simply add ?properties to the URL, tick the required functionalities and save! bob’s your uncle!

Using Rhino Mocks to test private methods on an abstract class

Firstly it is arguable that you should not be trying to directly test a private method on an abstract class, as tests should focus on the public methods, it should be upto the class where it uses private methods. However, if you do want to do this there is a way. In my case I was trying to use Test Driven Development to modify an existing code base without unit tests. Rather than retro-fit them to the rest of the code I wanted to minimise the code I was testing by directly testing a private method (which happened to be on an abstract class).

The method I chose used two sub-methods, one for testing abstract classes and one for testing private methods, and they actually fitted together really easily.

1. Use Rhino Mocks test the abstract class – Rhino Mocks allows for testing of abstract classes using the ‘partial mock‘ concept.
2. Use visual studio private accessors to access the private methods – If you have a version of Visual Studio that supports MS Test you can simply right click on a private method and choose ‘Create Private Accessor’. The accessor that is created accepts an instance of the class as a constructor, so when you pass in the Partial Mock created previously you end up with a class exposing the private methods as public that can be directly called… awesum!