Krzysztof Kozmic

On Testing: Why write tests?

Krzysztof Koźmic — Sat, 19 Jan 2013 08:19:00 GMT

This post is secod part of my Back to basics: on testing series.

Developers writing tests

People new to software, or coming from organizations where all testing is done by dedicated people often find the idea of developers doing testing bizarre.

After all, we're the highly trained, educated professionals. We get payed to do the hard bits. Clicking around the UI to see if a label is misaligned or an app crashed surely should be delegated to somebody else, outsourced even.

Truth is, there are various kinds of tests, and while there is value in UI tasting (automated or not) we'll concetrate at somethig else first.

You write the tests for your future self

The idea of developers writing tests came not from academia but from the field. From people who spent years developing successful software. And as you get out there, and start working with teams of people, on real life big systems that solve real problems, you realise that some things you belived (or in fact were taught) to be true, are not.

We'll get into the details as we progress with this series, but let's start with the biggest one:

The code is written, and read, and read, and read and read some more and modified, and read, and modified again, and read some more again and then few months later read yet again and again

You may notice there's much more reading than writing there. That is true for most code - you don't just write and forget it, like is the case with coding assignments at unversity. Real-life code is long lived, often expanded and modified and commonly the person doing the expanding is not the person who originally wrote the code. In fact the original author may have already moved on to work elsewhere.

How do you know what the code does?
How do you know where to make the change?
How do you know your change didn't break any of the assumptions that code interacting with the bit you changed makse about it?
How do you know the change you made works the way you wanted it to?
How do you know the API you created (in other words the public methods) are easy to use and will make sense to the other developers using it (that may also be you few weeks from now!).

These are the reasons for writing tests. Tests are the most economical way of ensuring the change you will make two months from now fit in the design constrants you designed today. Tests are the fastest way for other developers (or again, future you) to get a feel of how a piece of code works; what it does, and how you're supposed to use it.

Don't just take my word for it

In the next part of the series we'll start looking at actual code, writing some tests, and explaining the concepts around them.

Until then, if you have any questions, or suggestions as to what to cover in future posts of the series, feel free to leave a comment.

On testing

Krzysztof Koźmic — Tue, 27 Nov 2012 06:43:00 GMT

Over the last few years I've been mostly blogging about various random topics. Most often those were related to Windsor, discussing its new and upcoming features, announcing releases, and taking in-depth look and its underpinning principles.

Another bucket was one-off posts discussing various aspects of software development, mostly out of larger context and not really caring if you, dear reader, have the experience and understanding of the topic or not.

Back to basics

Recently I had an interesting discussion with several people on twitter about basics. More precisely about basics behind writing tests.

It seems to me, and I'm guilty of that myself, that us, the developers, chasing the latest great thing forget about the basics. When was the last time you read a blogpost about the importance of testing? When was the last time you read about how to write tests, what to look out for, and how to keep the quality of your tests high and the maintenance cost low?

Several years ago I got a lot of value myself by reading blogs that taught me what is important in software, and I wouldn't be the developer I am today, if it wasn't for those people, who dedicated their time to share their experience and knowledge.

I may not be subscribing to the right blogs anymore, but I noticed those posts are much less frequent these days. To help fill the void I decided to concentrate a bit more on the fundamentals in the future, starting with what will hopefully evolve into a series of blogposts about tests.

Feedback

Do you think it's a good idea? Any particular topics you would like me to emphasise, and areas to explore? Let me know in the comments. First post will be coming soon(ish).

IoC container solves a problem you might not have but it's a nice problem to have

Krzysztof Koźmic — Mon, 22 Oct 2012 22:03:00 GMT

On frameworks and libraries

A logging framework helps you log what's happening in your application. A UI framework helps you render and animate UIs to the user. A communication library helps connecting parts of a distributed system. All of these tasks and concepts are pretty easy to understand. They are quite down to earth, and therefore, at a high level at least, easy to explain. They produce tangible, additive difference in your application. Also the code of your application changes in order to use those frameworks and libraries. You add a logging framework, you write some code against its API and you end up with a file on your disk, or some text in your console. You add a communication library, inherit some base classes, implement some interfaces to designate communication endpoints of your application and you can see two processes exchanging information. I hope you get the picture and I don't need do go on describing the tangible, additive and visible results of using a UI framework.

What about IoC container?

So what about inversion of control containers? There's a lot of confusion around what they do, and why you should use one at all. Every now and then I meet a developer, who says they read all the definitions, introductions and basic examples, and they still don't get why would they use a container. Other times I'm having discussions that can be summarised as (slightly exaggerated for dramatic effect):

I got one of the IoC containers, put it in my application, and then all hell broke loose. We got memory leaks, things weren't appearing where they should, users were seing other users' data, we had to recycle the pool every hour because we were running out of database connections, and the app got very slow. Ah and also it destroyed maintainability of our code, because we never knew when something is safe to refactor, since we never knew where and who would try to get them from the container.

Let's ignore the details for now and concentrate on the wider sentiment.

So? Should I use it or not?

The sentiment is one of confusion, scepticism and frustration. Was it a good idea to use the container? Should we have not used it? Would I use it if I was leading the team? Truth is, those aren't necessarily the right questions to ask. You can't answer them in a vacuum. Should I use my phone to twitter when I'm on the bus? While the answer might be "sure, why not" if you're a passenger, it would be unequivocally "don't even think about reaching for your phone" if you're the driver. I have seen applications where introducing a container immediately, would only worsen things. I also haven't worked with any .NET application where, if architected the way I like to do things, the container wouldn't be beneficial in the long term. It all boils down to the fact that container solves certain problems that arise if and when you build your applications a certain way, and unless you do, you're not going to see the benefits it brings, simply because the problems container solves will not be the main problems you'll be facing, or will not appear in your application at all.

What sort of architecture are we talking about?

Container has certain requirements in order to work smoothly. First and foremost it requires structure and order. At a mechanical level, container takes over certain level of control over low level, mundane details of your application's infrastructure. It is however still a tool, and unless the environment where it operates is clean, with well defined limited number of abstractions it will struggle, and so will you, trying to get it to work.

There's a lot of content in the sentence above so let's dig a bit deeper.

The assumption containers are making is, that you do have abstractions. Getting a little bit ahead of ourselves, one of the main reason for using the container is to maintain lose coupling in our code. The way we achieve this is by constructing our types in such a way that they do not depend directly on other concrete classes. Regardless if it's a high level type, or low level type, instead of depending on one another directly, container expects they will depend on abstractions.

Another, related (pre)assumption is you will build your classes to expose abstractions. And not just in any way, but keep them small and crisp (structure and order, remember). To maintain loose coupling, the abstractions are expected to provide just a single small task, and most classes will provide just a single abstraction.

It is not uncommon for a concrete class to provide more than one abstraction (for example to bridge two parts of the system) but in that case the container assumes you will separate these two responsibilities into two abstractions.

Large number of abstractions in your system will be reusable, that is a single abstraction will be exposed by more than one type. In cases like that, the container assumes all the implementations will obey the contract of the abstraction, that is they will all behave in a way that will not be surprising to anyone consuming the abstraction without knowing what concrete implementation is behind it.

The point above is especially important to provide class level extensibility. Certain types in your system will depend on a collection of dependencies, and you should not have to go back and change them, whenever you add a new type ending up in that collection. The assumption is, the code using the abstractions, as well as the abstractions themselves are built in such a way, that the type can be extended by swapping (or adding new) dependencies it has, without the type itself having to change.

That's a lot of assumptions, isn't it?

You may say the container makes quite a number of assumptions (or requirements!) about how your application is structured. You wouldn't be wrong.

However if you look up and read the previous section again, forgetting that we are talking about container, does this feel like an architecture you should be striving for anyway? Does it feel like good, maintainable object oriented architecture? If it does, then that's good, because that's intentional.

A container doesn't put any artificial or arbitrary cumbersome constraints onto how you should build your application. It doesn't ask you to compromise any good practices aiming at maximising testability, maintainability and readability of your code and architecture. On the contrary, it encourages and rewards you for that.

It's the inversion!

Finally we're at a point where we can talk about some answers. The container makes a lot of assumptions about how your code is structured for two reasons.

That makes the container different from logging framework or communication framework. None of them cares about how your code is structured. As long as you implement correct interfaces or inherit correct base classes, and are able to call the right API they don't care.

Inversion of control containers are fundamentally different. They do not require your code to implement or inherit anything and there's no API to call (outside of single place called composition root). Just by looking at code of your application, you can't tell if there is a container involved or not.

That's the inversion of control working. This is what confuses so many people when they first start using containers. The difference is so fundamental from most other frameworks and libraries that it may be hard to comprehend and make the switch.

Inversion of control confuses people and makes it harder to see the value a container brings because the value is not tangible and it is not additive.

Contrast that with the examples from the first section. With logging framework you can point a finger at a piece of code and say "There, here's the logging framework doing its thing". You can point a finger at your screen, entry in Windows event log, or a file on disk and say "There, here's the result of logging framework doing its thing".

Inversion of control container is just "out there". You can't see the work that it's doing by inspecting your code. That ephemeralness and intangibility is what confuses many new users and makes it harder for them to see the value the container brings to the table.

To make things even slightly more confusing for newcomers, when you're using a container you don't end up writing code to use the container (again, expect for a little bit of code to wire it up). You end up writing less code as a result of using the container, not more, which again is harder to measure and appreciate than code you can clearly see as a result of using other kinds of frameworks.

What isn't there...

The second reason why container makes all of these assumptions about your code is very simple. Unless your architecture follows these rules, you simply will not have the problems that the containers are built to solve. And even if you do, they will be far from being your main concern.

Building your application according to the assumptions that the container is built upon (I hope by now you figured out that they are just SOLID principles of good object oriented C# code) your application will be composed of types exposing certain characteristics.

Following Single Responsibility Principle will lead you down the road of having plenty of small classes.

Open Close Principle will lead you down the way of encapsulating the core logic of each type in it, and then delegating all other work to its dependencies, causing most of those small classes to have multiple dependencies.

Interface Segregation Principle will cause you to abstract most of those big number of classes by exposing an interface or an abstract class, further multiplying the number of types in your application.

Liskov Substitution Principle will force you to clearly shape your abstractions so that they can be used in a uniform way.

Finally, if you follow Dependency Inversion Principle your types will not only expose abstractions themselves, but also depend on abstractions rather than concrete types.

Overall you will have a big number of small classes working with a number of abstractions. Each of those classes will be concentrated on its own job and largely ambivalent (and abstracted from) about who is using it, and details of who it is using.

This leaves you with a problem of putting together a group of those small types (let's call them Components) in order to support a full, real life, end to end scenario. Not only will you have to put them together, but also, maintain and manage them throughout the lifetime of your application.

Each component will be slightly different. For some of them you will want to have just a single instance, that is reused everywhere, for others, you'll want to provide a new instance each time one is needed, or may be reuse instances within the scope of a web request, or any other arbitrary scope.

Some of them will have decommission logic, like Dispose method. Some of them will have ambient steps associated with their lifecycle, like "subscribe me to certain events in event aggregator when I'm created and them unsubscribe me when I'm about to be destroyed".

Also thanks to the power of abstractions and guarantees put in place by following Liskov Substitution Principle you'll want to compose some of the components using a further set of design patterns. You'll want to create Decorators, Chains of Responsibility, Composites etc.

Not to mention the fact that in addition to depending on abstractions exposed by other components (let's call them Services) your components may also have some configuration, or other "primitive" dependencies (like connection strings).

I hope you can see that the complexity of it all can quickly grow immensely. If you want to maintain loose coupling between your components, you will have to write a lot of code to put them together and maintain all the aforementioned qualities. The code to do that can quickly grow as well, both in size and complexity.

Container to save the day

Inversion of control containers exist to replace that code. I know it took me a while to get here, and I did it in a very roundabout way, but there you have it - that's what IoC containers do - they help you stay sane, and reduce friction of development when adhering to good Object Oriented Design principles in language like C#.

I know it's not a sexy and concise definition, and some of you will probably need to re-read this post for it to "click". Don't worry. It didn't click for me at first either. The value and goal of IoC container is abstract and intangible, and the nomenclature doesn't help either.

The i-word

Some people feel that a lot of misconceptions and misunderstanding about containers comes from their very name - inversion of control container. If you just hear someone say those words, and leave it to your imagination, you'll most likely see... blank. Nothing. It's so abstract, that unless you know what it means, it's pretty much meaningless.

To alleviate that some people started referring to containers as Dependency Injection container. At first this sounds like a better option. We pretty much understand what dependency in context of relation between two objects is. Injection is also something that you can have a lot associations with, software related or otherwise. Sounds simpler, more down-to-earth, doesn't it?

It does sound like a better option, but in my experience it ends being a medicine that's worse than the disease. While it doesn't leave you with blank stare, it projects a wrong image of what a container does. By using the word injection it emphasises the process of constructing the graph of dependencies, ignoring everything else the container does, especially the fact that it manages the whole lifetime of the object, not just its construction. As a result of that, in my experience, people who think about containers in terms of DI end up misusing the container and facing problems that arise from that.

That's why, even though I'm quite aware Inversion of Control Container is a poor name, that doesn't help much in understanding those tools, at least it doesn't end up causing people to misunderstand them.

In closing

So there you have it. I admire your persistence if you made it that far. I hope this post will help people undersand what a container does, and why putting it in an application that's not architected for it, may end up causing more problems than benefits.

I hope it made it clearer what having a container in a well designed application brings to the table. In fact I only spoke about the most basic and general usages scenario that every container supports. Beyond that particular containers have additional, sometimes very powerful features that will add additional benefit to your development process.

So even if you feel you don't have a need for a container right now, having the problems that the container is meant to solve is often a sign of a good, object oriented architecture, and those are good problems to have.

To constructor or to property dependency?

Krzysztof Koźmic — Wed, 05 Sep 2012 12:32:00 GMT

Us, developers, are a bit like that comic strip (from always great xkcd):

We can endlessly debate over tabs versus spaces (don't even get me started), whether to use optional semicolon or not, and other seemingly irrelevant topics. We can have heated, informed debates with a lot of merit, or (much more often) not very constructive exchanges of opinions.

I mention that to explicitly point out, while this post might be perceived as one of such discussions, the goal of it is not to be a flamewar bait, but to share some experience.

So having said that, let's cut to the chase.

Dependencies, mechanics and semantics

Writing software in an object oriented language, like C#, following established practices (SOLID etc) we tend to end up with many types, concentrated on doing one thing, and delegating the rest to others.

Let's take an artificial example of a class that is supposed to handle scenario where a user moved and we need to update their address.

public class UserService: IUserService
{
   // some other members

   public void UserMoved(UserMovedCommand command)
   {
      var user = session.Get<User>(command.UserId);

      logger.Info("Updating address for user {0} from {1} to {2}", user.Id, user.Address, command.Address);

      user.UpdateAddress(command.Address);

      bus.Publish(new UserAddressUpdated(user.Id, user.Address));
   }
}

There are four lines of code in this method, and three different dependencies are in use: session, logger and bus. As an author of this code, you have a few options of supplying those dependencies, two of which that we're going to concentrate on (and by far the most popular) are constructor dependencies and property dependencies.

Traditional school of thought

Traditional approach to that problem among C# developers goes something like this:

Use constructor for required dependencies and properties for optional dependencies.

This option is by far the most popular and I used to follow it myself for a long time. Recently however, at first unconsciously, I moved away from it.

While in theory it's a neat, arbitrary rule that's easy to follow, in practice I found it is based on a flawed premise. The premise is this:

By looking at the class' constructor and properties you will be able to easily see the minimal set of required dependencies (those that go into the constructor) and optional set that can be supplied, but the class doesn't require them (those are exposed as properties).

Following the rule we might build our class like that:

public class UserService: IUserService
{
   // some other members

   public UserService(ISession session, IBus bus)
   {
      //the obvious
   }

   public ILogger Logger {get; set;}
}

This assumes that session and bus are required and logger is not (usually it would be initialised to some sort of NullLogger).

In practice I noticed a few things that make usefulness of this rule questionable:

It ignores constructor overloads. If I have another constructor that takes just session does it mean bus is an optional or mandatory dependency? Even without overloading, in C# 4 or later, I can default my constructor parameters to null. Does it make them required or mandatory?
It ignores the fact that in reality I very rarely, if ever, have really optional dependencies. Notice the first code sample assumes all of its dependencies, including logger, are not null. If it was truly optional, I should probably protect myself from NullReferenceExceptions, and in the process completely destroy readability of the method, allowing it to grow in size for no real benefit.
It ignores the fact that I will almost never construct instances of those classes myself, delegating this task to my IoC container. Most mature IoC containers are able to handle constructor overloads and defaulted constructor parameters, as well as making properties required, rendering the argument about required versus optional moot.

Another, more practical rule, is this:

Use constructor for not-changing dependencies and properties for ones that can change during object's lifetime.

In other words, session and bus would end up being private readonly fields — the C# compiler would enforce that once we set them (optionally validating them first) the fields in the constructor, we are guaranteed to be dealing with the same (correct, not null) objects ever after. On the other hand, Logger is up in the air, since technically at any point in time someone can swap it for a different instance, or set it to null. Therefore, what usually logically follows from there, is that property dependencies should be avoided and everything should go through the constructor.

I used to be the follower of this rule until quite recently, but then it does have its flaws as well.

It leads to some nasty code in subclasses where the base class has dependencies. One example I saw recently was a WPF view model base class with dependency on dispatcher. Because of that every single (and there were many) view model inheriting from it, needed to have a constructor declared that takes dispatcher and passes it up to the base constructor. Now imagine what happens when you find you need event aggregator in every view model. You will need to alter every single view model class you have to add that, and that's a refactoring ReSharper will not aid you with.
It trusts the compiler more than developers. Just because a setter is public, doesn't mean the developers will write code setting it to some random values all over the place. It is all a matter of conventions used in your particular team. On the team I'm currently working with the rule that everybody knows and follows is we do not use properties, even settable ones, to reassign dependencies, we're using methods for that. Therefore, based on the assumption that developers can be trusted, when reading the code and seeing a property I know it won't be used to change state, so readability and immediate understanding of the code does not suffer.

In reality, I don't actually think the current one, or few of my last projects had even a requirement to swap service dependencies. Generally you will direct your dependency graphs from more to less volatile objects (that is object will depend on objects with equal or longer lifespan). In few cases where that's not the case the dependencies would be pulled from a factory, and used only within the scope of a single method, therefore not being available to the outside world. The only scenario where a long-lived dependency would be swapped that I can think of, is some sort of failover or circuit-breaker, but then again, that would be likely dealt with internally, inside the component.

So, looking back at the code I tend to write, all dependencies tend to be mandatory, and all of them tend to not change after the object has been created.

What then?

This robs the aforementioned approaches from their advertised benefits. As such I tend to draw the division along different lines. It does work for me quite well so far, and in my mind, offers a few benefits. The rule I follow these days can be explained as follows:

Use constructor for application-level dependencies and properties for infrastructure or integration dependencies.

In other words, the dependencies that are part of the essence of what the type is doing go into the constructor, and dependencies that are part of the "background" go via properties.

Using our example from before, with this approach the session would come via constructor. It is part of the essence of what the class is doing, being used to obtain the very user whose address information we want to update. Logging and publishing the information onto the bus are somewhat less essential to the task, being more of an infrastructure concerns, therefore bus and logger would be exposed as properties.

This approach clearly puts distinction between what's essential, business logic, and what is bookkeeping. Properties and fields have different naming conventions, and (especially with ReSharper's 'Color identifiers' option) with my code colouring scheme have significantly different colours. This makes is much easier to find what really is important in code.
Given the infrastructure level dependencies tend to be pushed up to base classes (like in the ViewModel example with Dispatcher and EventAggregator) the inheritors end up being leaner and more readable.

In closing

So there you have it. It may be less pure, but trades purity for readability and reduces amount of boilerplate code, and that's a tradeoff I am happy to make.

Using ConventionTests

Krzysztof Koźmic — Thu, 14 Jun 2012 08:19:00 GMT

About conventions

I’m a big fan of using conventions when developing applications. I blogged about it in the past (here, here and later here). I also gave a talk about my experience with this approach and how I currently use it at NDC last week (slides are available here, video should be posted in a few weeks).

One problem I faced when trying to build convention validation tests was lack of simple API that would allow me to build the validation rules for my tests. I built a spike of such library (called Norman) last year. It was meant to be full-featured generic convention-validation engine, built on top of Mono.Cecil that would be able to validate rules inside method bodies (think rules like “no ViewModel can call data access code”). I quickly abandoned it, not being able to come up with simple and concise API that at the same time would be generic enough to cover every possible scenario.

About ConventionTests

Having failed with Norman’s approach on a later project I approached the problem from a completely different angle. This is based on observation regarding conventions I tend to use – they, in majority of cases, tend to be based on information about types, and internal models of frameworks I tend to use. In other words – information that can be easily obtained via plain Reflection.

Also limiting myself to very few scenarios allowed me to come up with a focused, simple and concise API. That’s how ConventionTests project was born.

Using ConventionTests

ConventionTests is a simple code-only Nuget that provides very minimalistic and limited API enforcing certain structure when writing convention tests and integrating with NUnit (more on that below). Installing it will add two .cs files to the project and a few dependencies (NUnit, Windsor and ApprovalTests).

ConventionTests.NUnit file is where all the relevant code is located and __Run file is the file that runs your tests (why that is, later).

The approach is to create a file per convention and name them in a descriptive manner, so that you can learn what the conventions you have in the project by just looking at the files in your Conventions folder, without having to open them.

Each convention test inherits (directly or indirectly from IConventionTest) interface. There’s an abstract implementation of the interface, ConventionTestBase and a few specialized implementations for common scenarios provided out of the box: Type-based one (ConventionTest) and two for Windsor (WindsorConventionTest, non-generic and generic for diagnostics-based tests).

Type-based convention tests

The most common and most generic group of conventions are ones based around types and type information. Conventions like “every controller’s name ends with ‘Controller’”, or “Every method on WCF service contracts must have OperationContractAttribute” are examples of such conventions.

You write them by creating a class inheriting ConventionTest, which forces you to override one method. Here’s a minimal example:

public class Controllers_have_Controller_suffix_in_type_name : ConventionTest

{

    protected override ConventionData SetUp()

    {

        return new ConventionData

            {

                Types = t => t.IsConcrete<IController>(),

                Must = t => t.Name.EndsWith("Controller")

            };

    }

}

Hopefully the code is self-explanatory (it was designed to be). You specify two predicates. One to find types that your convention is concerning, and the other specifying what your convention demands. If you now run tests in your project (or in __Run.cs file) You will see the result similar to this:

In this case I had a single class implementing IController, named Foo, which obviously doesn’t follow the convention that’s why the test failed, giving me generic failure message which just lists the types that failed the test.

To make it more readable I may want to make the test failure message more descriptive and actionable so that whoever sees a failing test like this will be able to know why their code is wrong and how to fix it.

protected override ConventionData SetUp()

{

    return new ConventionData

        {

            Types = t => t.IsConcrete<IController>(),

            Must = t => t.Name.EndsWith("Controller"),

            FailDescription = "Routing will not work unless controllers are named {something}Controller",

            FailItemDescription = t => t.ToString() + ". Name should be " + t.Name + "Controller perhaps?"

        };

}

The two additional properties will cause the failure to look like this:

This tells the developer who sees that test not only were the problem is, but also why it is a problem, and suggests a solution.

For scenarios where the convention is not all black and white and there are some legitimate exceptions to the rule there is built in integration with ApprovalTests framework (I blogged about ApprovalTests here). I know that the convention I used here as an example is pretty black and white but assuming it wasn’t changing the code to:

protected override ConventionData SetUp()

{

    return new ConventionData

        {

            Types = t => t.IsConcrete<IController>(),

            Must = t => t.Name.EndsWith("Controller"),

            FailDescription = "Routing will not work unless controllers are named {something}Controller",

            FailItemDescription = t => t.ToString() + ". Name should be " + t.Name + "Controller perhaps?"

        }.WithApprovedExceptions("Let's say Foo has special routing or something");

}

will change it to approval test where approved file will contain the output of the test, so in this case:

Windsor-based convention tests

Another common set of convention tests I tend to write are tests regarding my IoC container (and I tend to use Castle Windsor, therefore that’s the one supported out of the box). The structure of the tests and API is similar, with difference being instead of types we’re dealing with Windsor’s component Handlers.

public class List_classes_registered_in_Windsor : WindsorConventionTest

{

    protected override WindsorConventionData SetUp()

    {

        return new WindsorConventionData(new WindsorContainer()

                                                .Install(FromAssembly.Containing<AuditedAction>()))

            {

                FailDescription = "All Windsor components",

                FailItemDescription = h => BuildDetailedHandlerDescription(h)+" | "+

                    h.ComponentModel.GetLifestyleDescription(),

            }.WithApprovedExceptions("We just list all of them.");

    }

}

In this case we’re dealing with slightly different types but we follow the same pattern. We initialize the container and then specify predicates (if necessary) on its handlers. We don’t need to do that in which case all handlers from the container will be considered. This is useful to create (approval) test like this one that just lists all the components in the container, along with the list of services they expose and their lifestyle. With that you get quick insight into what’s in your container by just looking at the approved file. Moreover every change to the list of components will cause the test to fail, drawing your attention, to hopefully validate that the changes happening are indeed what you were expecting.

Windsor diagnostics-based convention tests

Windsor as some built in diagnostics and there’s a base class for tests that take advantage of that. For example the following test will list all potentially misconfigured components.

public class List_misconfigured_components_in_Windsor : 

    WindsorConventionTest<IPotentiallyMisconfiguredComponentsDiagnostic>

{

    protected override WindsorConventionData<IHandler> SetUp()

    {

        return

            new WindsorConventionData<IHandler>(

                new WindsorContainer().Install(FromAssembly.Containing<AuditedAction>()))

                {

                    FailDescription = "The following components come up as potentially unresolvable",

                    FailItemDescription = MisconfiguredComponentDescription

                }.WithApprovedExceptions("it's *potentially* for a reason");

    }

}

In this case instead of inspecting all handlers we go through handlers returned by the diagnostic (there’s another base class, with two generic parameters for diagnostics that do not deal with handlers). We make it an approval test so we can have an approved list of false-positives.

Those are the basic scenarios provided out of the box, however you can extend it to easily support more custom scenarios. For example, one case that happened on my current project just this week, was this. We’re using NHibernate and FluentNHibernate (by convention) and the default cascading on collections is set to “cascade all delete orphans”. This is not always the valid choice and for those cases we use mapping overrides.

Custom convention tests

We wanted to create a convention test (with approval) that lists all our collections where we do cascade deletes, so that when we add a new collection the test would fail reminding us of the issue, and forcing us to pay attention to how we structure relationships in the application. To do this we could create a base NHibernateConventionTest and NHiibernateConventionData to create similar structure, or just build a simple one-class convention like that:

public class List_collection_that_cascade_deletes:ConventionTestBase

{

    public override void Execute()

    {

        // NH Bootstrapper is our custom class to set up NH

        var bootstrapper = new NHibernateBootstrapper();

        var configuration = bootstrapper.BuildConfiguration();

        var message = new StringBuilder("Collections with cascade delete orphan");

        foreach (var @class in configuration.ClassMappings)

        {

            foreach (var property in @class.PropertyIterator)

            {

                if(property.CascadeStyle.HasOrphanDelete)

                {

                    message.AppendLine(@class.NodeName + "." + property.Name);

                }

            }

        }

        Approve(message.ToString());

    }

}

This is obviously much more imperative and much less readable than the other tests, therefore I suggest in most casese you make the effort and try to make the tests as terse, readable and declarative as possible so that they truly read like a good executable documentation.

And if you’re not sure how something works, remember the whole thing is a code-only nuget so you can just read the code.

Get it here.

How to force Nuget not to update log4net to 1.2.11

Krzysztof Koźmic — Tue, 31 Jan 2012 12:28:00 GMT

That’s a quick one. There’s been a new release of log4net recently that’s signed with a new key, and therefore is incompatible with old version 1.2.10.

Therefore, due to near-ubiquity of the library in .NET space, it may cause some problems if you happen to have a dependency (direct or indirect) on it.

The matters are made worse by Nuget’s default of getting the latest available version of the package. I dealt with this problem the other day, and I saw a few people in my twitter stream struggling with the same issue.

The solution is quite simple. It’s not specific to log4net and I’m not picking on log4net here. Here’s how you can restrict Nuget’s package to specific version in your solution.

So imagine you install a package that has a dependency on log4net. In this case, the dependency is specified as specifically version 1.2.10 (as opposed to Nuget’s default: this version of newer).

If after that we install another package that also depends on log4net but doesn’t restrict the version, we’ll have a problem.

The package we were trying to install doesn’t get installed. Actually, even if it did, we would have a problem since it most likely was compiled against log4net 1.2.10 anyway, and if Nuget updated log4net to version 1.2.11 the app would throw an exception at runtime due to mismatched assembly.

So there is a solution to restrict version of the package to specific version (in this case 1.2.10) as specified in the documentation.

After adding allowedVersions=”[1.2.10]” we can try again and this time the package will install properly.

Notice it says it installed log4net 1.2.11. I checked my packages folder, and project dependencies and the version referenced was 1.2.10 so all is good.

Hope that helps

Testing framework is not just for writing… tests

Krzysztof Koźmic — Wed, 18 Jan 2012 13:06:00 GMT

Quick question – from the top of your head, without running the code, what is the result of:

var foo = -00.053200000m; 

var result = foo.ToString("##.##");

Or a different one:

var foo = "foo"; 

var bar = "bar"; 

var foobar = "foo" + "bar"; 

var concaternated = new StringBuilder(foo).Append(bar).ToString(); 

var result1 = AreEqual(foobar, concaternated); 

var result2 = Equals(foobar, concaternated);

public static bool AreEqual(object one, object two) 

{ 

    return one == two; 

}

How about this one from NHibernate?

var parent = session.Get<Parent>(1); 

DoSomething(parent.Child.Id); 

var result = NHibernateUtil.IsInitialized(parent.Child);

The point being?

Well, if you can answer all of the above without running the code, we’re hiring. I don’t, and I suspect most people don’t either. That’s fine. Question is – what are you going to do about it? What do you do when some 3rd party library, or part of standard library exhibits unexpected behaviour? How do you go about learning if what you think should happen, is really what does happen?

Scratchpad

I’ve seen people open up Visual Studio, create ConsoleApplication38, write some code using the API in question including plenty of Console.WriteLine along the way (curse whoever decided Client Profile should be the default for Console applications, switch to full .NET profile) compile, run and discard the code. And then repeat the process with ConsoleApplication39 next time.

The solution I’m using feels a bit more lightweight, and has worked for me well over the years. It is very simple – I leverage my existing test framework and test runner. I create an empty test fixture called Scratchpad.

This class gets committed to the VCS repository. That way every member of the team gets their own scratchpad to play with and validate their theories, ideas and assumptions. However, as the name implies, this all is a one-off throwaway code. After all, you don’t really need to test the BCL. One would hope Microsoft already did a good job at that.

If you’re using git, you can easily tell it not to track changes to the file, by running the following command (after you commit the file):

git update-index --assume-unchanged Scratchpad.cs

With this simple set up you will have quick place to validate your assumptions (and answer questions about API behaviour) with little friction.

So there you have it, a new, useful technique in your toolbelt.

Approval testing – value for the money

Krzysztof Koźmic — Mon, 16 Jan 2012 12:29:00 GMT

I am a believer in the value of testing. However not all tests are equal, and actually not all tests provide value at all. Raise your hand if you’ve ever seen (unit) tests that tested every corner case of trivial piece of code that’s used once in a blue moon in an obscure part of the system. Raise your other hand if that test code was not written by human but generated.

As with any type of code, test code is a liability. It takes time to write it, and then it takes even more time to read it and maintain it. Considering time is money, rather then blindly unit testing everything we need to constantly ask ourselves how do we get the best value for the money – what’s the best way to spend time writing code, to write the least amount of it, to best cover the widest range of possible failures in the most maintainable fashion.

Notice we’re optimising quite a few variables here. We don’t want to blindly write plenty of code, we don’t want to write sloppy code, and we want the test code to properly fulfil its role as our safety net, alarming us early when things are about to go belly up.

Testing conventions

What many people seem to find challenging to test is conventions in their code. When all you have is a hammer (unit testing) it’s hard to hit a nail, that not only isn’t really a nail, but isn’t really explicitly there to being with. To make matters worse the compiler is not going to help you really either. How would it know that LoginController not implementing IController is a problem? How would it know that the new dependency you introduced onto the controller is not registered in your IoC container? How would it know that the public method on your NHibernate entity needs to be virtual?

In some cases the tool you’re using will provide some level of validation itself. NHibernate knows the methods ought to be virtual and will give you quite good exception message when you set it up. You can verify that quite easily in a simple test. Not everything is so black and white however. One of diagnostics provided by Castle Windsor is called “Potentially misconfigured components”. Notice the vagueness of the first word. They might be misconfigured, but not necessarily are – it all depends on how you’re using them and the tool itself cannot know that. How do you test that efficiently?

Enter approval testing

One possible solution to that, which we’ve been quite successfully using on my current project is approval testing. The concept is very simple. You write a test that runs producing an output. Then the output is reviewed by someone, and assuming it’s correct, it’s marked as approved and committed to the VCS repository. On subsequent runs the output is generated again, and compared against approved version. If they are different the test fails, at which point someone needs to review the change and either mark the new version as approved (when the change is legitimate) or fix the code, if the change is a bug.

If the explanation above seems dry and abstract let’s go through an example. Windsor 3 introduced way to programmatically access its diagnostics. We can therefore write a test looking through the potentially misconfigured components, so that we get notified if something on the list changes. I’ll be using ApprovalTests library for that.

     [Test]

    public void Approved_potentially_misconfigured_components()

    {

        var container = new WindsorContainer();

        container.Install(FromAssembly.Containing<HomeController>()); 

        var handlers = GetPotentiallyMisconfiguredComponents(container);

        var message = new StringBuilder();

        var inspector = new DependencyInspector(message);

        foreach (IExposeDependencyInfo handler in handlers)

        {

            handler.ObtainDependencyDetails(inspector);

        }

        Approvals.Approve(message.ToString());

    }

    private static IHandler[] GetPotentiallyMisconfiguredComponents(WindsorContainer container)

    {

        var host = container.Kernel.GetSubSystem(SubSystemConstants.DiagnosticsKey) as IDiagnosticsHost;

        var diagnostic = host.GetDiagnostic<IPotentiallyMisconfiguredComponentsDiagnostic>();

        var handlers = diagnostic.Inspect();

        return handlers;

    }

What’s important here is we’re setting up the container, getting the misconfigured components out of it, produce readable output from the list and passing it down to the approval framework to do the rest of the job.

Now if you’ve set up the framework to pup-up a diff tool when the approval fails you will be greeted with something like this:

You have all the power of your diff tool to inspect the change. In this case we have one new misconfigured component (HomeController) which has a new parameter, appropriately named missingParameter that the container doesn’t know how to provide to it. Now you either slap yourself in the forehead and fix the issue, if that really is an issue, or approve that dependency, by copying the diff chunk from the left pane to the right, approved pane. By doing the latter you’re notifying the testing framework and your teammates that you do know what’s going on and you know it’s not an issue the way things are going to work. Coupled with a sensible commit message explaining why you chose to approve this difference you get a pretty good trail of exception to the rule and reasons behind them.

That’s quite an elegant approach to a quite hard problem. We’re using it for quite a few things, and it’s been giving us really good value for little effort it took to write those tests, and maintain them as we keep developing the app, and the approved files change.

So there you have it, a new, useful tool in your toolbelt.

API design challenge – builder

Krzysztof Koźmic — Sat, 31 Dec 2011 01:07:00 GMT

Now that Windsor 3 is released I can concentrate on some of my other ideas and projects. While working on one of them, called Cartographer, I encountered an interesting API design problem.

I have a class (a builder to be precise) that has a task of setting up a central object (an IMapper implementation) in Cartographer (If you’ve ever used Autofac, it is somewhat analogous to ContainerBuilder). What is interesting about it, is I have three goals for that class:

Provide API for high level configuration and extension points that are universal to and intrinsic to any IMapper implementation.
Provide API for low level configuration of the default IMapper implementation that the builder creates, that will meet the following criteria:
1. Not force user to customize anything, as the default setup should be enough to get started in most cases.
2. Allow users to easily swap/extend parts of the dependency chain of the default mapper.
3. Work well and be natural both with and without IoC container .
Be simple and discoverable to the users (and provide good Intellisense experience).

How would you design the API for this class?

Oh, and happy new year.

Castle Windsor 3.0 is released

Krzysztof Koźmic — Fri, 16 Dec 2011 12:55:00 GMT

After successful beta and RC releases final version of Castle Windsor (as well as Castle Core, and a whole set of facilities) has now been released. There are no major changes between final version and RC. The difference is some minor bug fixes, improved exception messages and some small improvements all over the place.

The packages are available now, on Nuget (with symbols), and via standard .zip download.

Last but not least - thank you to everyone who downloaded beta and release candidate and provided feedback. You guys rock.

Getting closer… Castle Windsor 3 RC 1

Krzysztof Koźmic — Sun, 20 Nov 2011 12:10:00 GMT

Few weeks later than originally expected but here it is – Castle Windsor 3.0 (along with its facilities and Castle.Core) achieved release candidate status.

There is one major new feature in this release: registration API gained ability to specify properties to ignore/require. There are some scenarios where that’s useful, for example where integrating with some 3rd party framework that forces you to inherit from a base class which exposes its dependencies as properties. Creating pass-through constructors for each inherited class can be mundane. In those cases you can simply mark those base class properties as required, in which case Windsor will not allow them to be resolved unless all base property dependencies are satisfied. PropertyFilter enum supports several other most common scenarios, and for advanced cases there’s an overload that gives you more control.

Container.Register(

    Classes.FromThisAssembly()

        .BasedOn<ICommon>()

        .Configure(c => c.Properties(PropertyFilter.RequireBase)));

To address performance hit at startup Windsor no longer enables performance counters by default. Now, you have to do it explicitly:

var container = new WindsorContainer();

var diagnostic = LifecycledComponentsReleasePolicy.GetTrackedComponentsDiagnostic(container.Kernel);

var counter = LifecycledComponentsReleasePolicy.GetTrackedComponentsPerformanceCounter(new PerformanceMetricsFactory());

container.Kernel.ReleasePolicy = new LifecycledComponentsReleasePolicy(diagnostic, counter);

Full changelog is included in the packages. Please, if possible, take the time to upgrade to this version and if you find any issues report them so that the final release is rock solid. If no major issues are found, the final release will be published in two weeks.

The binaries are available on Nuget right now, and soon on our website.

Connector: Simple, zero friction Github –> AppHarbor integration

Krzysztof Koźmic — Sun, 18 Sep 2011 09:53:00 GMT

Recently to play with some new technology I came up with an idea to build an integration layer between Github and AppHarbor. What that means, is give you ability to work with your Github repository, reaping benefits of all of it’s VCS-centric features, and automatically, continuously deploy your code to AppHarbor.

The actual scenario I had in mind is to be able to use that for deployment of Open Source projects. AppHarbor is fantastic, no-headache deployment in the cloud, but Github is perfect for keeping and developing your code in the open, in social way. To have the cake and eat it too, Connector was born.

I hope you find it useful. it is free, use-at-your-own-risk-and-don’t-sue-me-if-something-breaks software. There’s still some work to be done, feature-wise and a whole lot of polishing but I decided to announce it early and get early feedback. If you have any suggestions, ideas or (gulp) bugs, let me know!

link: http://connector.apphb.com/

Hope that helps.

Windsor 3 beta 1 – dozen of Nuget packages and SymbolSource.org support

Krzysztof Koźmic — Sun, 04 Sep 2011 10:47:00 GMT

As promised, I released Nuget packages for beta 1 of Windsor 3. This is my first major rollout of Nuget packages, so please report any issues working with them.

Nuget and beta packages

Nuget is quickly evolving and getting more useful with each release. However one feature it’s missing right now is support for pre-release packages (this is coming in the next version).

This is not really a big deal, however it means there are a few things you should be aware of.

Recommended version

Since the new package is a pre-release, while I would really like for everyone to start using it immediately and report all issues they find, I quite understand that many people will rather prefer to stick to the last official version for the time being. To accommodate that the new packages are not made recommended versions, so your Nuget explorer will still point to the last stable (2.5.3) version if you search for Windsor, Castle.Core or any other pre-existing package.

If you go to command line and install one of the packages without specifying version number, it will install the latest, that is beta 1 version.

SymbolSource.org and debugging into Windsor

Folks at SymbolSource.org added recently support for Nuget (and OpenWrap as well) and the new Castle packages take advantage of that. What it gives you, is you can now easily debug into Windsor’s code, just like .NET framework reference source (there’s a simple guide at SymbolSource on how to do it).

After you’re all set you can step into any of Castle methods in your debugger and watch the magic happen. Very cool thing, even if I say so myself.

List of packages

Here’s the full list of v3 beta 1 packages (notice those are not all Castle packages, just those that were published as v3 beta 1 rollout of Windsor):

Castle.Core – Contains Castle.Core.dll which includes DynamicProxy, DictionaryAdapter, EmailSender, logging abstractions and some other goodies.
Castle.Core-log4net – Contains Castle.Services.Logging.Log4netIntegration.dll, that is implementation of Castle logging abstractions for log4net
Castle.Core-NLog – Contains Castle.Services.Logging.NLogIntegration.dll, that is implementation of Castle logging abstractions for NLog
Castle.Windsor – Contains Castle.Windsor.dll which has Windsor itself and two most commonly used facilities – Typed Factory facility and Startable facility.
Castle.LoggingFacility – Contains logging facility.
Castle.Windsor-log4net – Empty package that just installs logging facility and Castle.Core-log4net (and their dependencies obviously).
Castle.Windsor-NLog – Empty package that just installs logging facility and Castle.CoreNLog (and their dependencies obviously).
Castle.WcfIntegrationFacility – Windsor’s WCF facility.
Castle.SynchronizeFacility – Windsor’s Synchronize facility.
Castle.RemotingFacility – Windsor’s Remoting facility (extracted out of Castle.Windsor.dll)
Castle.EventWiringFacility – Windsor’s Event Wiring facility (extracted out of Castle.Windsor.dll)
Castle.FactorySupportFacility– Windsor’s Factory Support facility (extracted out of Castle.Windsor.dll)

I hope this will make it easier for everyone to test drive Windsor. And if you find any issues, have any suggestions or ideas, do not hesitate to bring them up, either on our google group, or issue tracker.

Simple guide to running Git server on Windows, in local network (kind of)

Krzysztof Koźmic — Sat, 20 Aug 2011 07:50:00 GMT

Last year I found myself in a sudden and quick need to set up working environment for a team of four, and as I like Git very much, I wanted to use it as our VCS. The problem was, we weren’t allowed to use any third party provider, so GitHub was off the table. As I searched the Internet there were a few guides to set up team Git environment on Windows, but they all seemed very complicated and time consuming. For our modest needs we experimented a little and came up with a solution that was very simple, didn’t require any additional software to be installed anywhere and worked like a charm.

Recently I used it again on my current engagement, and one of my colleagues suggested I should blog it, so here goes.

Ready, steady, go

The guide assumes you already have your local Git set up. For that, there are plenty of resources on the Internet, including my own blogpost about Windows Git tooling.

The entire tricks works like this – expose folder containing your shared Git repository as Windows network share.

Step one – bare git repository

There are two twists to the entire solution – one of them is – your shared repository needs to be initialized with --bare flag.

Step two – Windows share

Second step is to expose the folder with our newly created repository on the Windows share. You also use your standard Windows mechanisms to control and limit access to the folder (make sure you give the developers write access!).

Step three – Map the share as network drive

This step is perhaps not exactly necessary but I couldn’t get it to work otherwise, so here comes the second twist. In order for your developers to be able to access the shared folder via Git they need to map it as network drive.

Step four – Add remote repository in Git and code away

Last step is the standard Git procedure – every developer on your team needs to add the repository sitting under their newly created network drive as remote. Notice the use of “file:///” prefix in front of the mapped drive name.

Step five

That’s all. I hope you find it useful, and if you know a way to eliminate step three, let me know in the comments.

Windsor 3 beta 1 is released (along with other goodies)

Krzysztof Koźmic — Mon, 15 Aug 2011 10:49:00 GMT

The title says it all. If you can’t wait grab the binaries here (Windsor with Castle Core and facilities) and here (just Core). Nuget package will hopefully follow soon.

What’s in it?

This is a major release and there’s quite a lot of new features, as well as some significant changes under the covers. There’s a high level overview of highlights for the release in the wiki, so please have a look there. More detailed changelog, and list of breaking changes is available as part of the package.

Remember it’s a beta release. Documentation and samples are still being updated and some features are not yet implemented or not fully baked. However it is very important that you don't wait for the final release to upgrade, so that we can find and fix all the issues before final release. I'm not asking you to use it in production, but I'd really appreciate if you'd take the time to branch your apps, try to upgrade, run your unit tests, play with new version, and report any issues you may find. And ask your colleagues, friends and random people on the street to do the same!

And if you find any issues, do report them.

Have fun and happy coding,
I hope you like it

Krzysztof Kozmic

On Testing: Why write tests?

Developers writing tests

You write the tests for your future self

Don't just take my word for it

On testing

Back to basics

Feedback

IoC container solves a problem you might not have but it's a nice problem to have

On frameworks and libraries

What about IoC container?

So? Should I use it or not?

What sort of architecture are we talking about?

That's a lot of assumptions, isn't it?

It's the inversion!

What isn't there...

Container to save the day

The i-word

In closing

To constructor or to property dependency?

Depen­den­cies, mechan­ics and semantics

Tra­di­tional school of thought

What then?

In clos­ing

Using ConventionTests

About conventions

About ConventionTests

Using ConventionTests

Type-based convention tests

Windsor-based convention tests

Windsor diagnostics-based convention tests

Custom convention tests

How to force Nuget not to update log4net to 1.2.11

Testing framework is not just for writing… tests

The point being?

Scratchpad

Approval testing – value for the money

Testing conventions

Enter approval testing

API design challenge – builder

Castle Windsor 3.0 is released

Getting closer… Castle Windsor 3 RC 1

Connector: Simple, zero friction Github –> AppHarbor integration

Windsor 3 beta 1 – dozen of Nuget packages and SymbolSource.org support

Nuget and beta packages

Recommended version

SymbolSource.org and debugging into Windsor

List of packages

Simple guide to running Git server on Windows, in local network (kind of)

Ready, steady, go

Step one – bare git repository

Step two – Windows share

Step three – Map the share as network drive

Step four – Add remote repository in Git and code away

Step five

Windsor 3 beta 1 is released (along with other goodies)

What’s in it?

Dependencies, mechanics and semantics

Traditional school of thought

In closing