Of course I am only repeating what others are preaching about the recent rise of JavaScript.

But I think the movement is significant and can’t be overstated. And recent developments are really even making it more and more interesting.

Nobody can deny hat JavaScript is the de facto programming language of Html5. Every other language trying to bolt itself onto Html5 looks like pure friction so far. And Html5 is looking upon a prospering future.

Today we are used to some established JavaScript frameworks that make working with JavaScript more fun and productive. jQuery seems to emerge as the clear leader by popularity here.

More recently tons of javascript application frameworks (so called MVC frameworks) are emerging, that facilitate programming complex applications inside the browser and taking most of the traditional presentation-logic away from the server.

On the other hand we have the node.js ecosystem that takes JavaScript to the server and allows us to use the same language, concepts, libraries and tools for the full application development stack.
And that ecosystem is thriving! JavaScript is the most popular langage on GitHub … and have a look at the impressive node modules list.

Now this is all well and alpha-geeky, but there are showing up the first “real-world” success stories: Voxer, Walmart, LinkedIn …

Of course there are the critics.

Surprisingly Microsoft recently positioned itself to become one of the most influencing conveyor of the JavaScript hype. It seems that they are investing heavily into JavaScript on different frontiers:

Microsoft was pushing node.js onto the the Windows environment.
Now they are pushing it into their Azure cloud platform. And evolving a 3rd party ecosystem around that.

But probably the biggest step for the future of JavaScript is the new strategy of Microsoft for Windows 8 desktop and tablet applications (Metro style apps). While there are several options for developing Metro style apps, JavaScript seems to become a major pillar.
This opens up yet another area for JavaScript and JavaScript developers, completely adjacent to the web.
Developing for the desktop (or tablet) will most likely always be pretty different than for the web. For Metro style apps there will be a lot of new concepts, libraries and tools that are different to the ones that are used in web development (just have a look at WinRT, WinJS …).
But the desktop- and the web-stack will move closer together and JavaScript with HTML5 and CSS will be the common denominator. Which I think is a very interesting evolution.
For instance look at this example of a drum sequencer (a traditional client application) that is using JavaScript and jQuery for its UI.
The prospect of reusing code and knowhow between desktop-ui- and web-ui-programming seems tempting … even if a lot of .NET developers and other gurus are not so thrilled by the prospect of omnipresent JavaScript.

Of course another interesting thing will be to see how Metro style apps will change the architecture of future desktop applications. I think some concepts from web development will get adopted into desktop development. A stricter enforcement of separation between UI- and backend-components within a single application will most probably be a result (i.e. there seems to be no notion of traditional data-access in WinRT).

If you like this, follow me on twitter …

This is the introduction posts about dynamic client / server localization which describes the problem domain. In one of my current projects, we are building a client / server application that uses windows communication foundation requests and responses and event driven data, which is fired over the distributed event broker. Some of the data is dynamically rendered on the client but needs to be translated into several languages. For information which is already known at compile time localization is really straight forward with WPF. But what about data which is not known at compile time of the client?

To see the difference between localizible data which is known at compile time and dynamic data we need to look how static data can be localized in WPF. We use the WPF Localization Extension. We just have to reference the localization extension and then we can define localizible data in the XAML like:

<Window x:Class="Product.Name.SomeView"
        xmlns:l="http://schemas.root-project.org/xaml/presentation">
	<StackPanel Margin="10">
        <Label Content="{l:LocText Product.Name:Main:Label_UserName}" />
		<Button Content="{l:LocText Product.Name:Main:Button_Cancel}" />
	</StackPanel>
</Window>

All we then have to do is to create a corresponding resource file Main.resx and its language equivalents (for example Main.de-ch.resx) which contains a key Label_UserName and a key Button_Cancel. The resource files get compiled into satellite assemblies and will be deployed with the client application. Whenever the user switches the language of the user interface the label and the button will contain localized information according to the selected language or text from the fallback resource (usually from the main resource file). So far so good. Let’s look into more advanced use cases.

Imagine we have the following WCF service which is used by the client:

public interface IOrderService
{
	IEnumerable<ValidationResult> ValidateOrder(Order order);
}

[DataContract]
public class ValidationResult
{
	public ValidationResult(string message) {
		this.Message = message;
	}

	[DataMember]
	string Message { get; private set; }
}

public class OrderService : IOrderService
{
	public IEnumerable<ValidationResult> ValidateOrder(Order order) {
		return new[] { new ValidationResult("Unable to process order. Customer creditworthiness validation is pending!") };
	}
}

The server might have some business rules which are only known on the server side. The client needs to dynamically render validation results in case an order is not valid. We want to have the flexibility to extend the business validation rules without changing the client application. The sample above would always give back a validation result with an English message text. If the client language would be another than English this would have no influence onto the validation message.

What if the validation takes a lot of time and we want to inform the client about the validation process with an event over the distributed event broker.

public interface IOrderService
{
	void ValidateOrder(Order order);
}

public class ValidatedEventArgs : EventArgs
{
	public ValidatedEventArgs(IEnumerable<ValidationResult> results) {
		this.Results = results;
	}

	public IEnumerable<ValidationResult> Results { get; private set; }
}

[DataContract]
public class ValidationResult
{
	public ValidationResult(string message) {
		this.Message = message;
	}

	[DataMember]
	string Message { get; private set; }
}

public class OrderService : IOrderService
{
	[EventPublication("distributed://OrderValidated", HandlerRestriction.Asynchronous)]
	public event EventHandler<ValidatedEventArgs> Validated = delegate { };

	public void ValidateOrder(Order order) {
		// start some asynchronous background task
		// immediately return to the client
		// when background task is finished, execute
		// this.OnValidated(new[] { new ValidationResult("Unable to process order. Customer creditworthiness validation is pending!") });
	}

	private void OnValidated(IEnumerable<ValidationResult> results) {
	     this.Validated(this, new ValidatedEventArgs(results));
	}
}

With this approach the client would also only retrieve untranslated validation results. In the next series of posts we are going into the nuts and bolts how a dynamic client / server validation can be achieved.

cross-post from bbv blog

When software projects grow both in age and size the developers often struggle with the structure of the code. It gets more and more difficult to find the class you have to change for a new requirement. In this post, I’ll show you how we organize our code and how we derive our structure directly from the requirements.

When you look at example code from the internet or how some frameworks (e.g. ASP.NET MVC) structure their code, you see that they most likely organize the code by layer or put classes of the same kind in the same place.

For example in Model-View-ViewModel and ASP.NET MVC samples you will see namespaces/folders named Views, ViewModels, Controllers, Entities, DataTransferObjects, Repositories and so on.

Layers they say!

Now, we all were told that layers are good. Mainly because they simplify the code due to the fact that layers higher in the hierarchy are only allowed to access layers further down in the hierarchy. That’s okay, but has nothing to do with structuring code.

Feature Features!

I made the experience that structuring code by feature results in a much simpler layout. The main reason for this is that all the classes you are currently working on are physically near to each other despite their kind. The view, view-model and so on of the customer search are all in the same place: under the namespace MyCompany.MyProduct.Customers.Search. Thus minimizing navigation in the solution explorer (Visual Studio). Furthermore, these namespaces do not grow when the software grows, only the number of namespaces increases due to new features being implemented. Now when I have to look for a class then I start by looking up the feature it is needed in, go to this namespace and find it there.

The namespace per feature approach gives you some additional advantages:

• when a feature has to be removed you can “simply” remove the namespace as a whole and you do not have to search through all the layer based namespaces
• the structure of your code reflects the features and not the technologies used (watch Architecture Deference to see why this is important)
• refactoring namespaces (e.g. introducing sub-features) is simple because only the feature you are currently working on is affected

“But what about assemblies?”

Remember that assemblies are used to deploy a program on a machine. If you have a client and a server you’ll need at least two assemblies, probably at least three because of shared code. But this is a completely different decision than structuring. When you split up your code into different assemblies to deploy to different sites, you should still use the same namespaces in these assemblies. Start with changing the default namespace in the project settings.

Agile, Scrum, User Stories, Product Backlog and getting a structure by feature

When you develop software in an Agile way and your requirements are given in the form of User Stories then deriving features and therefore namespaces is really simple.

1. Identify the Themes in your Product Backlog  (see Themes/Epics/User Stories)
2. Per Theme introduce a namespace. E.g. MyCompany.MyProduct.Theme1
3. Identify features within each Theme. Often these features are initially described by Epics. E.g. searching, editing
4. Per identified feature introduce a namespace below the Theme: MyCompany.MyProduct.Theme1.Feature1
5. When namespaces grow too big, introduce sub-namespaces according to sub-features. Always try to think in user actions and not in technological differences.

“But what about infrastructure code?”

Yes, there is code that is used by several features. This code should be put into the existing namespace per feature hierarchy and not into its own. You got this right when you don’t need to add using statements into each code file (.Net,  import for Java).

Code shared by MyCompany.MyProduct.Theme1.Searching and MyCompany.MyProduct.Theme1.Editing should be in MyCompany.MyProduct.Theme1.

“But my assemblies get really big! That slows me down because the time needed to build increases, especially when practicing Test Driven Development!”

I develop software test driven. That means that I build my code and run tests every few seconds (I try at least). Build time gets very important. Additionally, Visual Studio and Resharper don’t reward you with good performance once a project reaches a certain size.

Therefore, assemblies need sometimes to be split up even if deployed at the same location.

When splitting assemblies you should consider the principles of package design and you should split along feature/namespace boundaries. If you split by feature the code and the number of projects that have to be built to run a unit test is minimized; thus minimizing the time you have to wait for the test to run.

“But the framework I use already dictates me to use namespaces like view or viewmodel!”

You have two options: look for another framework or start with a namespace per feature inside the namespaces that were given by the framework. E.g. MyCompany.MyProduct.View.Theme1.Feature1

So, how do you structure your code? And why? Let me know in the comments section.

The new release of Ninject 3.0 comes with a new extension that adds support for factories to Ninject. It supports factory interfaces, Func and Lazy. In this blog post I will explain how they are used.

Why using factories?
The recommended way to use IoC containers is that the composition root of the application is the only place where the container is accessed. Unfortunately many application can’t create everything at once during the application start or at the beginning of a web/wcf request because not everything is known at this moment. Therefore these applications need a way to create new instances using the kernel at a later point. Preferably we want to do this without introducing a reference to the container. This is where factories come into play. Instead of injecting the kernel into classes that need to create new instances we inject a factory. This factory is responsible to create the new instances using the kernel. There are two ways to implement such a factory: A factory interface and as a Func or Lazy.

Factory Interface
The recommended way to add factories is to define an interface containing one or several methods to create the required dependencies as shown by the next code snippet.

public class Foo
{
	private IBarFactroy barFactroy;
	public Foo(IBarFactory barFactory)
	{
		this.barFactory = barFactory;
	}

	public void Do()
	{
		var bar = this.barFactroy.CreateBar();
		...
	}
}

public interface IBarFactory
{
	Bar CreateBar();
}

This interface is declared at the same place as the class that is using it. In the binding configuration it can now be bound using the new ToFactory() method. This tells Ninject that it shall automatically implement a factory class for the specified interface and inject a new instance of this factory into each object that request an instance of the factory interface.

kernel.Bind<IBarFactory>().ToFactory();

Sometimes it is necessary to pass some parameters to the new instance. This can be done very simply by adding those parameters to the factory method. The extension uses the convention that you have to use the same parameter names in the factory like you did in the constructor of the created object. The order of the parameters in the factory method and constructor do not have to match.

public class Foo
{
	private IBarFactroy barFactroy;
	public Foo(IBarFactory barFactory)
	{
		this.barFactory = barFactory;
	}

	public void Do(int x, int y)
	{
		var bar = this.barFactroy.CreateBar(x, y);
		...
	}
}

public interface IBarFactory
{
	Bar CreateBar(int x, int y);
}

public class Bar
{
	public Bar(int y, int x)
	{
	}
}

foo.Do(1, 2); // Creates a Bar instance with x = 1, y = 2

Behind the scenes Ninject will create a proxy that implements the specified factory interface and intercept all methods so that the proxy behaves like the following implementation of the factory interface:

public class BarFactory : IBarFactory
{
	private IResolutionRoot resolutionRoot;
	public BarFactory(IResolutionRoot resolutionRoot)
	{
		this.resolutionRoot = resolutionRoot;
	}

	public Bar CreateBar(int y, int x)
	{
		return this.resolutionRoot.Get<Bar>(
			new ConstructorArgument("y", y),
			new ConstructorArgument("x", x));
	}
}

Factory Interface – Named Bindings
Sometimes there is the need to create differnet instances of an interface using named bindings. The default instace provider of the extension has the convention that it tries to return an instance using a named binding whenever a method starts with “Get”. E.g. IFoo GetMySpecialFoo() is equal to

resolutionRoot.Get<IFoo>("MySpecialFoo");

Custom instance provider
In some cases the default instance provider doesn’t meet your requirements. In this case you can do your own implementation with a custom behavior. This is done by implementing the IInstanceProvider interface:

    /// <summary>
    /// Provides instances to the interceptor.
    /// </summary>
    public interface IInstanceProvider
    {
        /// <summary>
        /// Gets an instance for the specified method and arguments.
        /// </summary>
        /// <param name="instanceResolver">The instance resolver.</param>
        /// <param name="methodInfo">The method info of the method that was called on the factory.</param>
        /// <param name="arguments">The arguments that were passed to the factory.</param>
        /// <returns>The newly created instance.</returns>
        object GetInstance(IInstanceResolver instanceResolver, MethodInfo methodInfo, object[] arguments);
    }

In most cases it is easier to derive from the StandardInstanceProvider and overload the required methods to change the behavior.

Func
The second way to add factories is to inject a Func to the class that needs to create a new object. Like the factory interface it supports arguments too. But since a Func gives you absolutely no information about the parameters you have to pass, I recommend not using Func unless it takes no arguments. Even if it takes no arguments I personally think factory interfaces is the cleaner way to add factories. You have to write more code but the readability is better than with Func.

public class Foo
{
	private Func<Bar> barFactroy;
	public Foo(Func<Bar> barFactory)
	{
		this.barFactory = barFactory;
	}

	public void Do()
	{
		var bar = this.barFactroy();
		...
	}
}

That’s everything you have to do in this case. There is no need to create a special binding for the Func.

Lazy
Sometimes the creation of a dependency must be postponed because it uses a lot of resources or it is heavy to create and rarely used. In this case you can inject Lazy instead of IDependency. This way, the creation of the dependency will be postponed until the Value of the Lazy is accessed the first time. This instance will be reused for all following accesses to Value.

public class Foo
{
	private Lazy<Bar> lazyBar;
	public Foo(Lazy<Bar> bar)
	{
		this.lazyBar = bar;
	}

	public void Do()
	{
		var bar = this.lazyBar.Value;
		...
	}
}

Ninject 3.0 release candidate has gone live. This release introduces some new feature and some changes in its behavior. This blog post will give you detailed information what has changed. It covers mainly Ninject core. Other blog posts that describe the changes and the new extensions will follow soon.

New fluent syntax to bind multiple interfaces to the same service
One of the big lacks of previous Ninject version was that there was no real support for the “Interface segregation principle”. It was not easily possible to tell Ninject that several interfaces shall be bound to the same service so that in case of a singleton the same instance is returned for different interfaces. Ninject provides now a fluent syntax that allows you to bind up to 4 interfaces together to the same instance:

Bind<IInterface1, IInterface2, IInterface3, IInterface4>().To<Implementation>(). ...;

Some may ask what is if I want to bind more than four interface to the same service. In a small discussion we came to the conclusion that if you have more than four interfaces on a single service than most likely you have a problem with the single responsibility principle and should fix this in first place. So I put the limit to four for the fluent syntax because adding additional ones means quite a bit of work in the implementation. For those that really need more interfaces there is a workaround though:

var bindingConfiguration =
    Bind<IInterface1, IInterface2, IInterface3, IInterface4>()
        .To<Implementation>()
        .BindingConfiguration;
kernel.AddBinding(new Binding(typeof(IInterface5), bindingConfiguration));
kernel.AddBinding(new Binding(typeof(IInterface6), bindingConfiguration));

Fluent syntax changes
Several changes for the fluent syntax were introduced:

• ToConstructor has been added. See Ninject constructor selection preview for detailed information.
• WhenInjectedInto previously matched only when the target type was exactly the specified one. Now it matches also if the target is derived from the specified type.
• WhenInjectedExactlyInto has been added for all those that want the previous behavior of WhenInjectedInto.
• WhenAnyAnchestorNamed has been added. Other than WhenParentNamed it does not match only if the parent has the specified name but also if any of its ancestors has the specified name.
• OnActivation and OnDeactivation receive now the implementation type instead of the service type as instance. In case the implementation type is undefined an object is passes as instance.
• Generic overloads for OnActivation and OnDeactivation have been added that allow casting the implementation type. This is required in case the implementation type is undefined.

Constructor selection and strong typed constructor arguments
This release introduces the new “To” fluent syntax overload “ToConstructor”. This overload allows you to select the constructor that shall be used in the fluent syntax and to specify constructor arguments strongly typed and without magic strings. For more information about this feature please read my previous blog post about this topic. Ninject constructor selection preview

Furthermore, the default selection of the constructor has been changed. Previous versions of Ninject considered constructors that have self bindable dependencies (e.g. a none abstract class) or dependencies for which a default value (int x = 3) is defined but no binding has been defined for those dependencies as invalid constructors and preferred all other constructors. In 3.0 these kinds of parameters are now treated the same way as if a binding exists for them. This can result in a different behavior of your application in case you have more than one constructor for your classes.

This version also requires that the constructor is uniquely selected. In case there is more than one constructor available with the same weight an activation exception is thrown. In this case you have to select the constructor manually (e.g. by using the new ToConstructor syntax).

Inherited constructor arguments
Previously it was possible to pass constructor arguments to the resolved object by passing ConstructorArgument to “Get”. This feature was extended so that it is now possible to pass the constructor arguments to deeper levels too using the following syntax:

kernel.Get<IFoo>(new ConstructorArgument("parameterName", value, true));
kernel.Get<IFoo>(new ConstructorArgument("parameterName", context => LazyEvaluatedValue(context), true));

Changed to client profile and removed InRequestScope
Version 3.0 is now build as client profile library. Since InRequestScope requires a reference to System.Web it was removed from Ninject core. This scope type is now provided by the new Ninject.Web.Common extension which is the base for all web type extensions.

Various small changes

• Support for constructor parameter with a default value has been added. If a constructor parameter has a default value it is used in case there is no explicit binding defined.
• Services that are bound using ToConstant are now in singleton scope by default. This decreases the work required when it is used somewhere.
• Open Generics bindings are now overridable by a closed generic binding of the same generic type.
• Instead of specially handling IKernel internal a default binding for IKernel and IResolutionRoot is added by the kernel during construction. This makes it possible to Rebind them if required.

Small extension changes

• Ninject.Extensions.ContextPreservation: BindInterfaceToBinding has been removed. Use the new Ninject core syntax to bind multiple interfaces to one implementation instead.
• Ninject.Extensions.Xml: InRequestScope requires the additional extension Ninject.Web.Common.Xml.

Over the last couple of years, I’ve done a lot of pair programming. Pair programming inside my team, at customer sites, in coding dojos and in my open source projects.

Pair programming is really a great and effective experience when performed by an pair of developers knowing how to pair program.

Unfortunately, you cannot just put two developers in front of a single computer and expect them to perform perfectly from the start. Pair programming has to be learned. Both developers need to learn the difference between being the driver (the one holding the keyboard) and the navigator. See here for details.

During my pair programming sessions I encountered some recurrent stereotypes, which I list in this post.

Navigator Stereotypes

The Dictator

The Dictator is a navigator who tells the driver what he has to type: “And now go to the end of the line and write a closing parenthesis and now…”. Instead of navigating by challenging the current solution and looking where to go next, the dictator gets caught in the programming details.

Actually, the Dictator wishes he had the keyboard. Therefore, when you encounter a dictator simply pass him the keyboard and switch to the navigator role.

The Spell Checker

The Spell Checker sits beside you and reacts to every typo you make by immediately correcting you. Of course, the spell checker has therefore not enough time to really navigate.

Make a deal with the Spell Checker that he gets you a coffee (or anything else you’d like) whenever he corrects you.

The Slasher

The Slasher is a navigator that criticises everything you write. While critique is good, he does it in a way without building upon what you already have built.

Like free jazz musicians build up a tune together by reusing what the other band members have played, good pair programmers use what is already there to go on.

Try switching roles and be a role-model navigator. Maybe the Slasher turns into an Ignorant though (see below).

The Silent

The Silent is a navigator who says nothing; or almost nothing. He just sits there and looks how you are working.

Challenge the Silent with questions about what he thinks about your solution, or which test to write next.

The Bored

The Bored tends to distract you from work instead of providing you with information helping you focus on problem solving.

Just send him away, it’s better to code alone than with a Bored.

Driver Stereotypes

The Secretive

The Secretive just types some code without telling what he is about to do. The navigator has to figure out what’s going on by himself. There is no discussion between the driver and the navigator about the route to go, which solution to follow or which design to choose.

As a navigator ask the Secretive what his plans are or what is the idea.

The Ignorant

The Ignorant simply ignores all advice of the navigator. Mostly because he thinks that his ideas or his programming skills are superior compared to those of the navigator.

When confronted with an Ignorant, simply stop pairing and rise the topic in the next retrospective. Ignorants are normally bad navigators, too. They probably turn into Dictators or Slashers.

The Overwhelmed

The Overwhelmed is simply not used to pair program and therefore very nervous and out of control.

Make sure that you are the best navigator you can be. Be extra cautious with critique and mainly support the Overwhelmed.

Unfortunately, most developers start with this stereotype. Therefore, don’t force pair programming to much on them and either let them be navigators first or only put navigators beside them who have enough social skills to handle the situation.

The Jumper

The Jumper is a driver who likes to make wild jumps in the source code so that it’s impossible for the navigator to follow his steps.

Slow the Jumper down by asking questions about his plans and make sure you know more short-cuts than him.

The Tool-Unfamiliar

The Tool-Unfamiliar does not know any shortcuts of the developer environment and is therefore simply a dead slow programmer.

Switch roles and show the Tool-Unfamiliar some of your tricks. Printing a cheat sheet with short-cuts helps a lot, too.

I’m sure there are other stereo-types. Let me know by writing a comment below!

Pair programming – two developers working together at a single computer – can result in better software written faster, but only if you know what you do.

Pair programming is not just sitting together and code as you would when being alone. Unfortunately, this is what most developers practice – resulting in a painful and ineffective experience.

To get most out of pair programming, you first have to know your setup.

Pair Programming for Transferring Know-How

This is the case when an expert and a novice pair together and the expert is coding while the novice is looking over the expert’s shoulder.

The expert shows the novice how something is done: coding style, design pattern, business logic concepts and so forth.

The novice gets an overview very quickly. However, the learning effect is rather low because of the passive role of the novice.

This kind of pair programming is very useful when introducing the novice to a new area.

Educational Pair Programming

When you switch the positions of the expert and the novice, you get educational pair programming. The expert coaches the novice while he tries to solve the problem. The learning effect is much greater in this kind of pair programming. But the speed of development is considerably lower.

Real Pair Programming

In real pair programming there are two experts working together to solve the problem at hand. Although they work at the same time on the same problem, their job is slightly different.

One (the driver) is responsible for

• typing code
• finding a solution that works

The other (the navigator) is responsible for

• challenging the current solution (what is missing? what could go wrong?)
• where to go next

This results in discussions about design, coding style, readability and much more. The outcome of such a pair programming session is a piece of code that is simpler, better understandable an less bug prone.

Pair Programming and Test Driven Development

Pair programming is especially powerful when developing software in Test Driven Development manner.

The driver is mainly responsible to get the failing test working by finding a quick solution (failing test phase). The navigator looks for test cases that show that the current solution is wrong or makes wrong assumptions (green tests phase). Together they look for simpler implementations (refactoring phase).

Why Pair Programming works

When practising real pair programming, both developers can concentrate on a single thing: Either finding a solution to the current problem, the current failing unit test, or challenging the current solution with new test cases.

This results in less switches between problem solving and problem analysing mode (red – green phases). Less switching between these two tasks results in higher efficiency¹ (less downtime because no task switch) and higher effectiveness² (navigator keeps focus on what has to be done and does not get lost in programming details). Finally, two developers can motivate each other much better to refactor code to get simpler solutions than a single developer does himself.

A final note: pair programming like any other methodology or practice has to be learned. Two developers cannot just sit together and expect to get benefits right away. Pair programming needs a lot of trust and discipline. Both has to be built first.

¹ efficiency = doing something quickly

² effectiveness = doing the right thing

Do you program or do you already TDD?
If you prefer to do TDD you will love the eclipse plug-in called MoreUnit. It is as simple as powerful. All it does is executing tests from corresponding productive class and makes it very simple to change between them.
Just press Ctrl-J (like Jump) to jump from test to implementing class and the other way. Or press Ctrl-R (like Run) to run the test regardless if you are in the test or the implementation class.

Configuration

There are just a few things you have to configure. I recommend to remove the prefix for tests because I name test classes like the original name with the suffix test.

Find classes with different names

If you have more than one test class for an implementation you prefer to decide into which test to jump. If you like this enable the option ‘Enable flexible naming of tests’. (At beginning I could not imagin who could have like this but since a short time I use it very intensive)

Mocks

There is a experimental feature to create mocks for dependencies. If you have a class which has a constructor to get some configurations MoreUnit is able to create initializing our testee with a mock. I tried it with mockito as mocking framework. My sample is a simple class which takes an object of type Param to be configured.

public class Feature {
 private final Param param;

 public Feature(final Param param) {
 this.param = param;
 }

 public void create() {
 System.out.println(param);
 }
}
public interface Param {
}

While creating the test with MoreUnit (just press Ctrl-J in the Feature class) it will as us in the second step of creation wizard which dependencies should be mocked.

As you can see I selected the constructor which takes an instance of Param. I don’t select any method to create a test method for it. So it will create a test class like this:

@RunWith(MockitoJUnitRunner.class)
public class FeatureTest {
 @Mock
 private Param param;
 private Feature feature;

 @Before
 public void createFeature() throws Exception {
 feature = new Feature(param);
 }
}

In my opinion this is not bad but, I’d prefere to have the initialisation for mocking within the @Before method and not with the @RunWith. Because sometimes I have other JUnit runners like the Parameterized.class. So I have to remove the @RunWith and add the ‘MockitoAnnotations.initMocks(this);’. So the test will look like this:

public class FeatureTest {
 @Mock
 private Param param;
 private Feature feature;

 @Before
 public void createFeature() throws Exception {
 MockitoAnnotations.initMocks(this);
 feature = new Feature(param);
 }
}

You might say: “If I have to do so much I just can write it on myself”. Nearly right. Imagin you have more than just one parameter. MoreUnit will create all the members with corresponding Annotations. There are some problems with the current version (2.4.2). Creating the mocks in an already existing test will have the result there is a second member for the unit under test and if the annotation @RunWith is already on the class it will be added twice. So it will be very helpful while creating a new test but not very comfortable if the test is existing and contains mocks.

Where to find

http://moreunit.sourceforge.net
Update-Site: http://moreunit.sourceforge.net/update-site
The plugin should also be available in the Eclipse Marketplace. Just search for ‘moreunit’

I think it is a very helpful tool if you will program with TDD. Because it helps you to change between implementation an test very quick. (Yes, much faster than Ctrl-F6, try it )

Implementing the dispose pattern according to IDisposable can be very tedious. Why not simply use the new Lazy<T> to get rid of some boiler plate code? The trick is to define a Lazy<Action> with a function delegate which calls a release method. As long as you don’t access the value property of the lazy type the release method is not called. Lazy<T> offers the possibility to check whether the underlying value has been created or not (property IsValueCreated). Therefore we can use this to check whether we already disposed the underlying resources. Let’s see how this looks like in code:

    public class SomeDisposable : IDisposable  {
        private Lazy<Action> dispose;

        public SomeDisposable()  {
            this.dispose = new Lazy<Action>(() => this.Release);
        }

        public void Dispose() {
            this.Dispose(true);
            GC.SuppressFinalize(this);
        }

        protected virtual void Dispose(bool disposing) {
            if (disposing && !this.dispose.IsValueCreated) {
                this.dispose.Value();
            }
        }

        private void Release() {
            this.resource1.Dispose();
            this.resource2.Disconnect();
            this.resource2.Dispose();
        }
    }

Remarks: I left out the finalizer to not clutter up the code sample too much.

Happy lazy coding!

The reporting mechanism allows creating a full report of the bootstrapping process. To be able to report the bootstrapping process the process must actually run and a reporter must be present. By default the bootstrapper uses a null reporter which does nothing with the report. But it is also possible to hook in a report generator which creates Visio, Enterprise Architect or … (you name it!) diagrams.

A custom reporter must implement the reporter interface IReporter. The reporter receives an IReportingContext which contains all necessary information about the bootstrapping process. The custom reporter must be passed upon the construction of the DefaultBootstrapper<TExtension>.

        new DefaultBootstrapper<ICustomExtension>( /* Input your IReporter */ )

The reporting context is structured like the following:

An example of a reporter which reports all into a string could look like:

        public class StringReporter : IReporter
        {
            private IReportingContext context;

            public void Report(IReportingContext context)
            {
                this.context = context;
            }

            public override string ToString()
            {
                return Dump(this.context);
            }

            private static string Dump(IReportingContext context)
            {
                var builder = new StringBuilder();

                context.Extensions.ForEach(e => Dump(e.Name, e.Description, builder, 0));

                Dump(context.Run, builder);
                Dump(context.Shutdown, builder);

                return builder.ToString();
            }

            private static void Dump(IExecutionContext executionContext, StringBuilder sb)
            {
                Dump(executionContext.Name, executionContext.Description, sb, 3);

                Dump(executionContext.Executables, sb);
            }

            private static void Dump(IEnumerable<IExecutableContext> executableContexts, StringBuilder sb)
            {
                foreach (IExecutableContext executableContext in executableContexts)
                {
                    Dump(executableContext.Name, executableContext.Description, sb, 6);

                    executableContext.Behaviors.ForEach(b => Dump(b.Name, b.Description, sb, 9));
                }
            }

            private static void Dump(string name, string description, StringBuilder sb, int indent)
            {
                sb.AppendLine(string.Format(CultureInfo.InvariantCulture, "{0}[Name = {1}, Description = {2}]", string.Empty.PadLeft(indent), name, description));
            }
        }

Restrictions: In the version 1.0 of the bootstrapper there is a limitation for lazy resolved behaviors. Lazy resolved behaviors do not report as the actual behavior but as a LazyBehavior type. Hope I can resolve this in the feature version.

Happy reporting!