Don’t use transitive dependencies in AngularJS modules

Whenever you write an AngularJS application, you will use modules. Modules divide you application into small logical pieces. Some pieces might depended on other, some might be totally independent.

In the example above, you see three modules. A module called MainModule depending on two other modules, called UserModule and UtilModule. Note that this is just a very simple example. In the real world, things become much more complicated.

Let’s assume the following dependency: UserModule depends on some service from UtilModule. However, we forgot to add this dependency to the modul declaration. But because we always run our MainModule for our application, everything will work perfectly fine, because MainModule will load the dependency which the other module will need. So we won’t see this hidden transitive dependency easily.

However, we have problem now: we don’t know anymore which dependencies our module has. Even worse, our module depends on another module, because it provides its dependencies. We end up with a cyclic dependency as MainModule depends on UserModule and vice versa. One cannot run without the other.

But why is that a practical, not just a theoretical problem?

It becomes a practical problem when it comes down to testing. Whenever you do unit testing, you want to test things isolated:

You want to test a small piece with as less dependencies as possible. But what happens if you did’t specify your dependencies right?

Well, you also need to load modules which you don’t actually need. This could easily break your test if something in the other module changes.

Keep your modules clean!

Best regards,

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,

Testing AngularJS directives with Jasmine


AngularJS provides a mechanism called directives. Directives are markers in our HTML which Angular will read and use to inject some special behavior to our HTML code. As this sounds a little bit theoretically, let’s look at an example:

In this example the directive ng-model is used which will bind the value of the input field to a field called name in the current $scope. This directive already comes with AngularJS, but it’s also possible to write your own directive. That’s what we do right now.

A custom directive

In order to have an useful example to test, we write our own directive. In this case we will use a directive which will listen for an “on-enter-event” on an element. It looks like that:

And you use it like that:

The example creates a directive called onEnter which you must refer as on-enter in your HTML. The directive takes a single argument which is a function in the current scope (e.g.: showNotification()). So when we type in your input field and press enter the directive will be called. It will get an event and it will check if the event comes from “enter” or another key. If it was an “enter”, the directive will call our method. Looks good? So let’s test it.


Testing this directive isn’t a big thing, but it will bring us the evidence that it works like we expect it. A Jasmine test might look like this:

What does the test do?

The test does the following: First we load the module which contains our directive and inject AngularJS’ $rootScope and $compile service. As a directive is attached to the HTML, we need to take some HTML and compile it with AngularJS in order to make the directive work like in a real life scenario.

Now we create our actual test case. First we create a spy function (jasmine.createSpy('test');) and attach it to our scope (which is simply the root scope). This function should be called by the directive if it works correctly. Now we create some HTML which uses the directive and compile it. The last thing we need to do is to create an on-enter-event and fire it up on the compiled element. This simulates the user pressing enter.

Last but not least we verify that the on-enter directive worked and has invoked our test function on the root scope.

What the test doesn’t do

The test only verifies the happy path. It tests if the function is called when enter is pressed, but it doesn’t verify the opposite: Is the directive only listening on “enter” or will it also call our function if another key is pressed? However, implementing this test shouldn’t be a big thing now.

Best regards,


Create random test objects with Java reflection

Although Java is an object oriented language, you will often separate our data and your actual business logic. You will write POJOs, entities, domain models and DTOs which you will pass to services, repositories and controllers. If you do so, you will properly need test data for those objects. Often, the data you pass will be very important as it represents the state of your application and business process. You must design it carefully to get the test results you are looking for. However, there are also some cases where the data isn’t so important – it must just be there! You need an object, filled with random data. That’s it.

Java’s reflection mechanism offers an easy method to create POJOs filled with random data. Here is a basic code snippet which will take a class, instantiate it and fills its fields with random data. Maybe it makes your test setup easier.

Best regards,

Everytime a mock returns a mock a fairy dies

As I was reading about some Mockito features last week, I stumbled over the following tweet, which really made me laugh:

I actually found the reference to the tweet in the Mockito source code about “deep mocking” and it’s worth to think about it for a minute…

Deep mocking

Deep mocking is a really great feature from Mockito. It lets a mock return a mock, which will return a mock, which will return a mock, which will… I think you got it. Here’s an example how it works:

By passing the Mockito.RETURNS_DEEP_STUBS argument to Mockito, we tell Mockito to make a deep mock. This makes it possible to mock the result of a complete method chain in the next step.

Use deep mocking for fluent APIs

Deep mocking is very elegant way to mock fluent APIs/interfaces which are very popular right now. Fluent APIs are described by Martin Fowler (here) and are often used for builders, factories, queries or configurations.

While method-call chaining is a really bad way to write code as it’s hard to read, hard to debug and hard maintain, fluent APIs are very handy to avoid repetition in the code (e.g. to write something like builder.setId(1); builder.setName("My Object"); ...) and to lead the developer through a certain process (e.g. an object creation). Since Java’s stream API they are also part of the core Java language. You will find them in many other places, too:

  • Java 8 streams:
  • Mockito: when(...).thenReturn(...)
  • Apache HTTP Client: Request.GET(...).connectTimeout(...).execute().returnContent()
  • Spring MockMVC: mockMvc.perform(get(...).accept(...)).andExpect(status().isOk())

Don’t use deep mocking for call chains

This brings me back to the tweet about the dying fairies on the top of this post. While the tweet doesn’t apply fluent APIs (IMHO), it definitely applies to bad written code. When every a mock returns a mock (and so on…) some encapsulation is broken. As you need to know details about the internal behavior of the mocked object (to mock it again), you are violating the Law of Demeter (the principle of least knowledge).

Fluent APIs vs. Code Chains

It’s important to know the difference between a smart and handy fluent API (which you might mock!) and a bunch of ugly code chains (which you better refactor!). Code chains break encapsulations and leak the internals of an object to the outer world. Fluent APIs on the other provide a small DSL (domain specific language) which doesn’t leek internals as it only returns the “next possible step” and guides you on your way.


Best regards,

Continuous Integration Development Workflow

This semester I attended an university course called System Engineering and Management taught by Prof. Walter Kriha. The course has a slightly different topic every year and is made up of presentations from students, research assistants and other lecturers. The topic in this year was continuous integration and software deployment. Together with Jan Müller, I set up a continuous integration environment to develop a Python web app.

Our demo app

We made a simple demo app to demonstrate your workflow and to show the purpose of the components in our CI environment. We build our app with Python and Flask on the server, a simple template rendering for the client and a MongoDB at the back-end. The app itself was a simple CRUD application to add, update and delete users from a list.

The CI environment



We used GitHub as our central repository and to communicate with the rest of the world. The idea (for a real world team) was to use GitHub as a repository, as a wiki, as an issue tracker and as a community tool, e.g. for pull requests. However, we did not push any code directly to GitHub! Here is why:


We used GerritHub as a review tool and as our central repository for all development tasks. To do this, GerritHub cloned the original repository from GitHub and automatically synchronized both of them. As a developer we checked out code from GerritHub (not from GitHub!) and also pushed our changes to GerritHub (and, guess what, not to GitHub directly!). After a new change was pushed to GerritHub, all developers of the project received an email notification about the change. The change itself had to be reviewed and approved in GerritHub by at least one other developer. Only after a change was reviewed and approved it went into our code base on GitHub (GerritHub merged it into the code based). This enforced a certain policy in our development process where every piece of code must be reviewed by somebody else.


After the code was pushed to GerritHub, approved there and merged into GitHub, it was time for our build system. We set up a so called post commit hook in GitHub, which informed our build system about code changes. So each time new code arrived from GerritHub in our GitHub repository our build system started a new build. Since our app was made in Python we decided to use BuildBot (which itself is made in Python) as our build system. However, what we did is possible with any other build system, too. BuildBot did a set of tasks for us:

  1. Check out the latest code from GitHub
  2. Execute all unit tests
  3. Run static code analysis such as PEP8
  4. Build an artifact to download
  5. Deploy the app to our demo machine

Demo machine

We set up a demo machine where our BuildBot deployed ever (successful) build. With this automated deployment we always had an up-to-date and running instance of our app. This is great as a team since everybody of the team can see the latest features and show them to potential customers.

Demo videos

I made a short (~10 minutes) video to demonstrate the development workflow in this environment. The video covers a full development cycle of a new feature from the first check-out of the project to the final result on the demo machine. I made a voice-over in English and in German, both should contain the same (more or less). The video is cut to make it as short as possible, so you won’t have to wait for my Eclipse to start…

What I do in the video is the following:

  1. Check out the project and run make sure it is in a stable state
  2. Implement a new feature in a test-driven way
  3. Push the new feature
  4. Watch BuildBot doing its work
  5. Enjoy the final result on our demo machine

Demo Video (English): CI Development Workflow


Demo Video (German): CI Development Workflow


Best regards,

A GPS diary in four weeks with Play!

During the last four weeks I did another small project for one of my university courses this semester. The course was about ORM modelling and abstractions for databases. We did some exercies with Hibernate and discussed diefferent aspects about ORM modelling. At the end of the course, every student made a small web-project using a framework and ORM tool of his choice.

Most of us used Play! and ebeans to make their application – me too. I didn’t have any experience with Play! but it was very pleasent to work with. Togehter with Foundation CSS prototyping was extremly fast. And ebeans also did a great job. During the whole project I didn’t write any line of SQL – nice!

Online demo

You can see a demo on Just log-in as with 123456 as your password to see a demo-account with some data.


My presentation about TAD:


The code is available on my university’s own Git repository, but it is public:

git clone

Best regards,
Thomas Uhrig

Java 8 in Eclipse (Juno)

Note: Here is an up-to-date tutorial for the new Eclipse versions Kepler and Luna:

Since last July the new Java 7 is generally available. However, even the newer Java 8 is already available as an Early Access Preview. It can be download as part of the OpenJDK including lambda-support. To use it with Eclipse, some additional steps are required. Here’s how it goes:

  1. Download the JDK from and install it.
  2. Create a new Java project in Eclipse.
  3. Change some project settings in Eclipse in order to use the new javac compiler of Java 8:
    1. Click right on your project and select Properties.
    2. Select Builders on the left side and uncheck the default Java Builder.
    3. Click on New and select Program as the type of the new builder.
    4. Open javac from the JDK 8 on your disk (it’s in the folder bin).
    5. Configure the new builder by providing some arguments:
    6. Select the tab Build Options and check the During auto builds box, to let the builder run automatically.
  4. Done! Now you can write and execute Java 8 code!

The main feature of Java 8 is the ability to write lambdas and use a functional-like programming style. This can be very useful, especially in GUI-programming. It can reduce the amount of code, because anonymous classes that only implements a listener-interface are avoided. Here’s a very simple example:

The code creates a common JFrame with two buttons. To each button an action-listener is added. But instead of implementing an anonymous class, a method reference is passed in the first case and a lambda in the second case. This reduces the amount of code compared with the old solution that looked like this:

However, the Java compiler will create exactly such a thing of the lambda expression or function reference. Therefore, the passed method must fulfill the interface described by ActionListener. Also, we can only use lambdas instead of interfaces that only describe one single method. Such interfaces are called functional interfaces.

Since Eclipse Juno is made for Java 7 it will not recognize the new lambda syntax. Hence, the editor will mark parts of the code as red errors. But it’s still possible to compile and to execute the code using the new javac compiler form Java 8.

Best regards,
Thomas Uhrig

Automated UI testing with Swing & FEST

Testing an application is hard, but testing an user interface (UI) is even harder. FEST addresses this issue for Java Swing applications. It enables you to write easy and readable functional tests for your UI. Working together with JUnit, it lets your functional UI tests feel like common unit tests within your test suite.

FEST is a context-sensitive testing-framework, which means that the position of your UI components, their size or color isn’t important for the test (of course you can tests this criteria if you want). FEST identifies all UI components by an unique ID – their name. Therefore, your UI layout can change, but the tests will still work.

By the way: Because all components in your UI must have a unique name, it’s a good idea to use a Factory to create your components and to make sure that they all have an unique name.

To start with FEST is really simple:

  1. Download FEST from their Google Code repository and put fest-swing-x.x.jar as well as all JARs in the lib folder of the ZIP-file to your classpath.
  2. Make a Swing UI, perhaps something like this:

  3. Now, go ahead and write a (JUnit) test:
  4. Let your test run and see how FEST is interacting live with your UI.

FEST uses the java.awt.Robot class to interact with your UI. Robot is part of the JDK since version 1.3 and provides a low-level API to simulate user interaction for AWT or Swing application. FEST encapsulate this class into an abstract and easy to use API.

The difference between common JUnit tests and functional tests using FEST is the level of test-execution. JUnit tests are working on isolated classes and methods whereas functional tests (with FEST) are working on the real UI shown to the user. This real UI can be composed of many single objects that should be tested altogether. Also, functional test doesn’t work on a method-level – they are working on the same level as the human user simulating “clicks”, “selects” and “keys”.


Best regards, Thomas Uhrig.