Inject mocks with Spring’s @ContextConfiguration

One of the biggest strengths of Spring is its ability to make your code testable. By using dependency injection and inversion of control, the Spring context defines which objects will be wired into your beans. This makes it easy to wire services, repositories or what ever you like. But how to wire mocks in your tests?


Let’s create a simple test setup: we have a service called OrderService which handles orders from customers. To do this, the OrderService needs a BillingService.

A typical test setup would run the Spring context, auto-wire the OrderService and test it. But if we would do so, we would also need to include the BillingService into the Spring context. And if the BillingService would need some other service, we would need to include this too and each and every transitiv dependency. Maybe we would end up by loading your whole app just to test one simple service.

A test setup with mocks

Whenever you want Spring to inject our beans, you must create a Spring context. Every bean you want to use must be part of this context as well as every transitiv bean. In this case we need two bean: (1) the OrderService which we want to test and the (2) BillingService which is a transitiv dependency. Both beans must be part of the Spring context!

However, we don’t want to use the real BillingService but a mock. To do this, we provide a dedicated @Configuration for our test which returns such a mock (with Mockito). If we would have other dependencies, we would do this for every bean used by the OrderService.

This makes it possible to load a very small Spring context: We only need our class to test and a mock very each of its dependencies. This is more like an unit test but an integration test and will run very fast. But the nice thing is, that you can decide which dependencies you want to mock and which not. If you would like to mock the BillingService but not the CustomerService it fine. You can control the amount of mocks very easily.

Best regards,

Use ranges with ngRepeat


Angular’s ngRepeat directive provides a simple way to iterate over collections to produce HTML dynamically. You probably know it when you have ever worked with lists or arrays in your Angular app:


However, there is a small drawback when working with ngRepeat: You can only iterate over collections of the current scope. Loop definitions (like a typical for-loop) are not supported. This means you cannot to something like this:

The solution

But there is a simple trick to build a workaround for this. If you use a library like Lodash.js or Underscore.js the trick becomes even more simple: As ngRepeat requires a function on the scope, we just provide such a function!

That’s all we need. If we append Lodash/Underscore to our scope, we can use the library within our partials. This might looks like this:

Keep in mind

With great power comes great responsibility. When we append Lodash/Underscore to the Angular scope, we not only pollute the scope with more functionality, we also put program logic from the controller to the partial. And we shouldn’t do that! A partial should be as easy as possible and all application logic should be in the controller or services. But this is also a trade-off, as this solution might be fine for small and simple problems.

Best regards,