Yet Another JavaScript Testing Framework

posted on May 22nd, 2009 ·

by Miško Hevery & Jeremie Lenfant-engelmann

Did you notice that there are a lot of JavaScript testing frameworks out there? Why has the JavaScript community not consolidated on a single JavaScript framework the way Java has on JUnit. My feeling is that all of these frameworks are good at something but none solve the complete package. Here is what I want out of JavaScript unit-test framework:

I want to edit my JavaScript code in my favorite IDE, and when I hit  Ctrl-S, I want all of the tests to execute across all browsers and return the results immediately.

I don’t know of any JavaScript framework out there which will let me do what I want. In order to achieve my goal I need a JavaScript framework with these three features:

Command Line Control

Most JavaScript test runners consist of JavaScript application which runs completely in the browser. What this means in practice is that I have to go to the browser and refresh the page to get my results. But browsers need an HTML file to display, which means that I have to write HTML file which loads all of my production code and my tests before I can run my tests. Now since browsers are sandboxes, the JavaScript tests runner can only report the result of the test run inside the browser window for human consumption only. This implies that 1) I cannot trigger running of the tests by hitting Ctrl-S in my IDE, I have to Alt-tab to Browser, hit refresh and Alt-tab back to the IDE and 2) I cannot display my test result in my IDE, the results are in the browser in human readable form only.

On my continuous build machine I need to be able to run the same tests and somehow get the failures out of the browser and on to the status page. Most JavaScript test runners have a very poor story here,  which makes integrating them into a continuous build very difficult.

What we need, is the ability to control test execution from command line so that I can trigger it from my IDE, or my continuous build machine. And I need test failures to be reported on the command line (not inside the browser where they are unreachable) so that I can display them in IDE or in continuous build status page.

Parallel Execution

Since most JavaScript test runners run fully in the browser I can only run my test on one browser at a time during my development process. In practice this means that you don’t find out about failures in other browser until you have checked in the code to your continuous build machine (if you were able to set it up) and your code executes on all browsers. By that point you have completely forgotten about what you have written and debugging becomes a pain. When I run my test I want to run them on all browser platforms in parallel.

Instant Feedback in IDE

After I hit Ctrl-S on my IDE, my patience for test results is about two seconds before I start to get annoyed. What this means in practice is that you can not wait until the browser launches and runs the tests. The browser needs to be already running. Hitting refresh on your browser manually is very expensive since the browser needs to reload all of the JavaScript code an re-parse it. If you have one HTML file for each TestCase and you have hundred of these TestCases, The browser may be busy for several minutes until it reloads and re-parses the same exact production code once for each TestCase. There is no way you can fit that into the patience of average developer after hitting Ctrl-S.

Introducing JsTestDriver

Jeremie Lenfant-engelmann and I have set out to build a JavaScript test runner which solves exactly these issues so that Ctrl-S causes all of my JavaScript tests to execute in under a second on all browsers. Here is how Jeremie has made this seemingly impossible dream a reality. On startup JsTestDriver captures any number of browsers from any number of platforms and turns them into slaves. As slave the browser has your production code loaded along with all of your test code. As you edit your code and hit Ctrl-S the JsTestDriver reloads only the files which you have modified into the captured browsers slaves, this greatly reduces the amount of network traffic and amount of JavaScript re-parsing which the browser has to do and therefore greatly improves the test execution time. The JsTestDriver than runs all of your test in parallel on all captured browsers. Because JavaScript APIs are non-blocking it is almost impossible for your tests to run slow, since there is nothing to block on, no network traffic and no re-parsing of the JavaScript code. As a result JsTestDriver can easily run hundreds of TestCases per second. Once the tests execute the results are sent over the network to the command which executed the tests either on the  command line ready to be show in you IDE or in your continuous build.


→ 34 CommentsTags: Uncategorized

How do you convince your boss to TDD

posted on May 16th, 2009 ·

A reader asks:

My boss knows about TDD but won’t allow us to use it because he thinks that it is just a passing hype that everyone talks about but no serious, big projects actually use it on daily basis. How could I convince him that it is not so?

This is an excellent question that takes me a bit by surprise, as I can’t imagine my boss dictating how I write code. :-) I don’t have an answer, but here is what I think I would do if I were in this situation. (I would also like to encourage other readers to share their thoughts on this topic and offer suggestions in the comments.)

Arguments don’t work

There is no magical argument I can make to convince someone that TDD is a good idea: logic may not be persuasive here, but experience is. I am not arguing here that 1 + 1 is 2, but rather that if you follow these practices, the result is subjectively better. Since there is so much subjectivity in this, people need to experience TDD to understand its benefits. It is very hard to learn TDD by someone trying to learn it from a book. Learning TDD is more like learning to ride a bike: You can read books on how to do it and you can have silly arguments with theorists on how you can’t ride a two-wheeled contraption because it is inherently unstable, but nothing makes you a believer more than actually riding a bike. The first time you ride a bike it is a very clumsy experience, and I would argue that it takes hours of falling and uncertainty until you are better at it than walking: don’t expect TDD to be any different. It is a skill that takes hours of practice to master. Don’t argue with someone over your experience; instead, make him live through the same experience.

Make sure you know what you are talking about

To me, nothing is worse than someone trying to sell something that he doesn’t fully understand. Make sure you are reasonably good at TDD and have built a reasonably sized application before you try to show someone else how to do it. Imagine someone who has only seen others riding bikes trying to teach someone to ride a bike: my guess is that he will only frustrate the person learning. For this reason, build a small app with TDD in your free time. Your first tests will be the hardest, and at times you will think “this is way more trouble than it is worth,” but keep in mind that you struggling because you are learning a new skill. You have been developing code the old way for years: What makes you think that you can pick up TDD overnight? TDD makes you think about tests first, something that you have never done. It will not come easy, but in time it will become second nature to you. It took about one year before I felt that writing code test-first was the natural flow of things.

Create a small project to show your boss how helpful tests are in refactoring

I cannot overstate the importance of learning TDD on a brand new project without deadlines. Start something new in your free time and build it with TDD. Use it as a learning experience. You will: discover all kinds of things about how to best write code, get a feel for telling apart helpful tests from those that get in the way, learn how to think about the problem from a test-first perspective, realize the importance of not getting ahead of your tests, and discover that your code looks nothing like what you envisioned. Code with tests looks different. Try to refactor code written test-first and you will see that some tests are helpful while others get in the way. You first have to live through this experience to become familiar with the kinds of tests that get in the way of refactoring, and to know how to turn them into the kinds of tests that help you refactor. To know both one and the other you have to first build something with TDD.

Since you will be struggling a lot at the beginning, trying to bring TDD to an existing project may only fuel your boss’s feeling that TDD is not useful. Again, TDD is a skill and takes a while to develop.

Tests help design

We all believe that good code is reusable code. For this reason most of us add all kinds of interfaces and abstraction in the name of reusability. But what percent of the code you have written have you actually reused? I would say a tiny fraction, very close to zero. One reason for this is that your code isn’t reusable, even though you believe it to be. Tests help ensure that your code is in fact reusable, because they force you to write classes that can be used both in production and in a test scenario. If you can’t write a test, you don’t have reusable code. If you write test-first, then it is very likely that the code is reusable: after all, you just used it in tests and in production. This is the single reason why test-first produces better design. On the other hand, if you write code as you always have, you will most likely end up with hard to reuse code. If you write tests afterward, then at best the tests are an afterthought hacked on top of the production code; such tests are very unlikely to help us when you are refactoring, since they are likely to produce false negatives.

Hardware folks have figured this out

Did you know that average chip can have as much as 50% of its silicon dedicated to testing? Why is it that every discipline out there takes testing seriously except software? I believe it is because of the presumed inexpensive nature of fixing bugs. A new rev of silicon is extremely expensive. As a result, most companies can only afford to rev it about 5 times. Can you imagine writing code such that you are only allowed to run the production 5 times? Yet hardware folks can’t imagine designing chips any other way. The cost of another software rev seems close to zero, and this is where people get into trouble: We believe that another build costs us (almost) nothing, and this belief becomes our death by a thousand cuts. The more complicated the project, the more likely it is that a fix in one location will cause a bug elsewhere: the project is forced into an endless cycle of regressions. Tests help here, but again, this needs to be experienced.

If you get stuck, spike

Sometimes you just have no idea how to write code test-first; there are a lot of reasons for this. Instead, you revert to good old fashion hacking. That isn’t a problem as long as, after you first code by hacking, you go back and write tests, or preferably, completely re-write the code test-first. you call this “spike”; I do this quite a lot when faced with new technology or environment. Just don’t let this become the way you develop software.

Vote with your feet

If your boss is micro-managing how you do things and you have tried everything to explain your position, you always have the right to vote with your feet. Last time I checked, we software engineers are in high demand, so there is no reason to work for people who are being counterproductive.

What do you think?

What do the readers think about how they could influence others to develop software test-first? Please leave your comments so that we all can learn from each other

→ 11 CommentsTags: Uncategorized

Configure your IDE to run your tests automatically

posted on May 7th, 2009 ·

When I develop code I write test first and always run my tests. But it can get rather tedious to run the tests manually every so often. Here is a common scenario. Your tests are green and you start doing whole bunch of refactorings which you think are trivial and safe. When you are done you run the tests and it is broken. The problem is that you did ten little things and you don’t know which of the ten things you did broke the code. The solution is to run the test more often, but we just forget.

What I want is to have my IDE run my tests every time I do a change without me doing anything. This way even though I am doing ten little changes the IDE runs the tests ten times. The moment you do something which you thing is safe but it turns out that it makes your tests fail your IDE should tell you. You than simply hit Cntl-Z (undo) and you are back in business.

What I want is for my IDE to run my tests every time I save the code. To do this my tests need to be fast, because my patience after hitting Cntl-S is about two seconds. Anything longer than that and I will get annoyed. If you start running your tests after every save from test zero you will automatically make sure that your test will never become slow, since as soon as your tests start to run slow you will be forced to refactor your tests to make them faster.

Obviously this technique is only useful for true unit-tests since they are fast. I do not run my scenario tests as part of Cntl-S.

I only know how to set this up on Eclipse, so perhaps people with IDE or NetBeans can chime in. I have already set up the project for you here so all you need to do is download and try it out. But here are the steps

  1. Create a Project: Eclipse has this cool feature which compiles your code continuously on every save. This is great, as what it really means is that your code is always compiled and you never have to wait for  a compilation step in eclipse.
  2. Create a JUnit Text runner as shown here: here
  3. Create an ANT build file which will run your text runner from the eclipse compiled folder. This way the ant does not have to continuously compile your code.
  4. Tell Eclipse to run your ant target after every compilation cycle. This is known as Builder in Eclipse.
    1. Open project properties: Right click project -> Properties
    2. Create new ant builder step after the Java Builder in eclipse: Builders -> new -> Ant Builder
    3. Give your builder a nice name. Here is what to do on each tab. (I thing eclipse has a bug and you need to hit Apply every time you change tabs)
      • Main: Select the build file; base directory (This specifies which ant filet to use)
      • Targets: Select your ANT target for: “After Clean”, “Manual Build”, and “Auto Build” (most important) (This specifies that after ever build it should also run your ANT target.)
      • Build Options: Check “Specify working set” and select all of your source folders. (This specifies which file changes will trigger this builder, in our case any file change)

Or just grab my repository form here and import the already made project 00_AutoTest and try it out.

Happy test running…

→ 19 CommentsTags: Uncategorized

The Problem With Active Record

posted on May 5th, 2009 ·

By John Januszczak

The Active Record pattern has gained a lot of attention lately, particularly because of it’s use in the wildly popular Ruby On Rails (“RoR’) framework. Other frameworks which employ the Active Record pattern include the Castle Project, which aims to simplify the creation of enterprise and web applications for .NET developers. If you are new to the Active Record design pattern, it is an object-relational mapping and object persistence pattern for binding business objects with database records. Specifically:

Active record is an approach to access data in a database. A database table or view is wrapped into a class, thus an object instance is tied to a single row in the table. After creation of an object, a new row is added to the table upon save. Any object loaded gets its information from the database; when an object is updated, the corresponding row in the table is also updated. The wrapper class implements accessor methods or properties for each column in the table or view.

Source: Wikipedia

Therefore, typical implementations of the Active Record pattern consist of instance properties representing a record’s fields in the database, instance methods that act on that specific record and static methods acting on all records, i.e. the database table or view. David Hayden gives a nice overview of how this pattern might be implemented in his article Active Record Design Pattern – Domain Driven Design and Domain Layer – Object Persistence.


I would hazard to guess that almost anyone who has developed web applications with Ruby On Rails would testify to the utility and even aesthetics of the Active Record pattern. For the record, I share this admiration. However, I can see problems lurking inside of the various implementations, in terms of both design principles and testability.

Problem #1: Static Methods

As mentioned above, each Active Record class maps to a corresponding database table (or view), and each instance of such a class maps to a record in that table. So, to create a new Account record you might do the following (I’ll use c# syntax):

Account newAccount = new Account();

You then might set some field values and save it:

newAccount.Name = "Joe";

However, if you want to get an account from the database you use a static method (because you are querying the whole table, not a specific record, to find it):

Account joesAccount = Account.Find("Joe");

Some would say using Static methods simply amounts to procedural programming, and therefore is poor Object Oriented design. Others would say static methods are death to testability.

Problem #2: Global Configuration Settings

In our example above, the Account class needs to connect to a database (or some source). You will find that most Active Record implementations have some kind of application config file. For example, Ruby On Rails uses a YAML file to persist the application’s database connection settings. Therefore there is no dependency injection on the Account class in my example, and by extension, on the Account instances.  As we should all know by now, looking for things is very, very bad!

Towards A Better Active Record

A better pattern might still include classes that represent the various database tables, but instead define separate logical state containers to represent the table’s records. Logical state containers are classes that simply define a set of fields with associated accessor methods/properties – you can almost think of it as a glorified struct.  The classes that represent the tables would be instantiated by passing the connection settings to its constructor:

AccountTable accounts 
  = new AccountTable(myConnectionSettings);

We can now query the instance of the database table that corresponds to our connection settings to retrieve records in the form of a simple logical state container:

AccountRecord joesAccount = accounts.Find("Joe");

Updates to the database would be done by passing instances of the proposed logical state containers into instance methods of the table classes:

joesAccount.Name = "Joe Jr.";

Separating responsibilities for the table and the records into two separate classes provides a better design and a decent shot at genuine testability.

→ 21 CommentsTags: Uncategorized

Managing Object Lifetimes

posted on April 15th, 2009 ·

There is a myth out there that creating objects is expensive. The result of this is that a lot of applications have objects whose lifetime is too long. Let’s take a web app for example. Most web-apps I have seen have too many long lived objects and not enough request scope objects, which has implication on how data flows through the application. A web app has at least three scopes: application, session and request scope. These scopes are in decreasing lifetime and most of the time they do not overlap (ie the request scoped objects die, before the session objects can die).

I believe objects should only maintain references to other objects that are equal or longer-lived. In other words, a request can know about session, but it is not a good idea for the session to know about a request. (When I say ‘know’, I mean that it does not have field reference to request, it can have temporary reference through the stack, i.e. method parameter.) The way a long lived object gets a hold of a short lived object is through the stack (passed in through a method parameter).We could generalize this rule to say: Pass in objects of equal and greater lifetime through the constructor and objects of shorter lifetime through the stack.

Now the interesting part is what happens when you start to break this rule. There are two ways to break this rule, lets look at them in turn.

When this rule is reversed (passing short lived objects into a long lived object constructor. i.e. session knows about request) you have a recipe for bugs, since now the garbage-collector will not be able to clean up the objects which are clearly out of scope. There is not much you can do with a request object after the http connection is closed. I see this mistake often, and usually developers solve this through some kind a clean up code. Recently, for example, I came across a game of GO which had a App and the Game class. Now App is lifetime of the application but Game is only for the duration of the game. In the code every time the user wanted to play a new game the App had to go through a cleaning process for a Game object, which was a source of errors. Your first game would behave right but your second game may not. Solution is to simply throw away the Game and instantiate a new one.  Now the App is responsible for instantiation of the Game object but the App does not keep a reference to the Game object (beyond the local reference on the stack.)

More common violation is to not have an appropriate life time object in the first place. For example let’s say that you have a web app and you don’t have any classes which are meant to be request scope, such as a Servlet. A servlet is application scoped, as a result, you cannot inject the request/response into the constructor, instead you have to pass them through a stack, which is exactly what happens. Now not all code is in your servlet, therefore your servlet needs to collaborate with other objects, but most of them are application scoped as well. Now let’s say that you have three application scoped objects A, B and C, such that A calls B, B calls C and A does not know about C directly (i.e. A->B->C). Let’s say that C needs the http cookie. The only way for me to get the cookie into C from my servlet is to pass it in as an argument to A, which than passes it to B, which than passes it to C. Sooner or later you will realize that this is a real pain, since every time C needs a new object reference you have to modify all of these unrelated objects. Therefore you will create a context object which knows about cookie and all of the other objects and you will be proud of yourself how clever you are. But a context is solving the wrong problem. The real problem is that C’s lifetime is wrong. If C’s lifetime would be that of cookie (request scope) than the Servlet could just pass it in directly like this:

HttpRequest request = ...;
C c = new C(request.getCookie());
B b = new B(c);
A a = new A(b);

Now this is great since A and B are no longer involved in the process of passing along the cookie. After all neither A nor B cares about the cookie. It also means that if at some later point in time C needs additional object such as request-path C can just ask for it in the constructor without having to change anything in A nor B.

Servlet becomes a place where the long lived object (servlet) meets short lived object (our ABC object graph). This means that whenever you have to cross the object boundary in reverse you need a factory, which is what our servlet does.

Therefore, whenever you get into situation when you have to pass objects through many layers, or that you create a context and than pass the context through the layers your layers are probably long lived and need to have their lifetime adjusted. You can generalize this and say that: Whenever a class has a reference to another object but does not directly dispatch methods on that object, than the collaborator which needs the object is of wrong lifetime.

→ 13 CommentsTags: Uncategorized

How to do Everything Wrong with Servlets

posted on April 8th, 2009 ·

When I interview people I often ask them what an evil developer would do to make his code hard to test. Servlets are a great example of what to do if you want it to be hard to test

Lets start with constructor. Constructor is the first thing I look at since it tells me about my dependencies. In the case of servlets the spec asks for no-argument constructor so that the container can control the instantiation process. This is all fine but how is my Servlet supposed to get a hold of its dependencies such as database connection or any other object which needs to be shared between multiple servlets? There is no good way! The only thing which I can do is to use global state and singletons for inter servlet communication (which we have covered in detailed here, here, and here).

Initialization process is no help here. Yes the container will call a init method, but the only thing I can get a hold of in the initialization process is the strings which I have placed in my XML. What I really want is to share instances of objects between servlets so that I can configure my collaborators. Again I am forced to result to global state and singletons. But there is something worse about this. Mainly the single responsibility principle. Each class is responsible for exactly one thing. But in our case the servlet is responsible for the logic, the wiring of itself to the collaborators and initialization of the collaborators. Now, I like to place my initialization in a single place so that I can control the order of initialization. But servlets make this difficult since the servlet container does not guarantee any order of initialization for your code. This means that each servlet is a potential source of initialization. Which again forces you to the singleton and lazy initialization model.

In Java you have single inheritance hierarchy, (which is a good thing) but Servlets take that away from you by forcing you to inherit from their class in essence giving you no inheritance choice at all. Inheritance should be used when we need to take advantage of polymorphism, but there is no polymorphism going on within servlets. What passible purpose does inheriting from HttpServlet serve which could not be addressed with an interface. Code reuse through inheritance is quite possibly the worst offense in software engineering. Composition over inheritance should always be the goal. The worse thing about this is it sets a precedence which is followed on most projects. Most web apps have deep inheritance hierarchies with Servlet at the top which seem to serve no other purpose than code reuse. Testing collaborators is easy since I can test each collaborator in isolation, but if collaboration is replaced with inheritance now my tests have to test the full inheritance hierarchy at once. Inheritance is all or nothing proposition.

OK, if you managed to survive the constructor, initialization, and inheritance, there are other subtle surprises waiting for you. We are building web apps, therefor the most common object lifetime should be equal to the duration of HTTP request. Instead we have servlets whose lifetime is lifetime of the JVM. This creates a huge problem since all of the HTTP request information/data now has to travel through the stack rather than being a part of the object. In other words we have static code-base and we push the data around through the method arguments. Sounds like procedural code to me. I don’t want to get into debate over OO vs Procedural, but I do want to point out that Java is OO, use it in that way. If you want to write rocedural code, use a procedural language. Play to the strengths of the language no to its weakness.

Surely there is nothing else which servlets do wrong. Ohh, but there is, let me introduce you to the Service Locators anty-pattern. The HttpServletRequest and HttpServletResponse are two huge service locators. They themselves hove nothing of interest, but they do have getter methods which have things which I need. Well actually, I don’t need that either. What I want is a User for example. What I have is request. Let’s see does this look familiar?

String cookie = request.getCookie();
long userId = cookieParser.parse(cookie).getUserId();
User user = userRepository.find(userId);

What I want is user but what I got is worthy of a Sherlock-Holms detective story as I try to piece together the identity of the user. If I had to do this in one location, I would not complain so much but I have to do this in every single servlet. Please, just give me the user, or whatever else which I need to get my work done. The thing is that request has cookie, but it is not the cookie I want, it is the user id which is embedded in the cookie. But it is not the user id, but the user i really want. This Law of Demeter violation is the direct result of two things: (1) service locator nature of the request / response and (2) the wrong lifetime of the servlet.

Now imagine trying to test this thing. First I have to call new, great that is easy as I have no argument constructor, but how do I get all of my mock dependencies into the servelet as collaborators? My only hope is setting some global state. But, wait the servlet is also responsible for initialization which means it is loaded with new operators, and those suck from the testability point of view. (see here) Now I really want to test the home page but the home page servlet inherits from the AuthorizedServlet which talks to the database to authenticate. Great now my every test needs to mock out the authentication even if it is not testing it. So if I change my authentication all my test are broken. Now I really just want to create a new User to test the home page but I have to place my user into a Mock Repository and assign a mock id. I than have to create a mock cookie and place it into a mock http request all the while hoping that I will be able to give you a mock UserRepesitory through some global state.  I wish I was making this up, but Servlets are untestable in their current form.

Let’s see if we can solve these problems. First forget servlets and create your own classes which have your own minimal inheritance with preference for composition with object lifetime which equals that of the HTTP request so that your collaborators can ask for objects such as User directly in the constructor. This way testing your code is easy. Now for the servlet part, Since our code is HTTP servlet, request and response free it is both easy to test and incompatible. Therefor the job of the servlet is to call the new operators to build the object graph of collaborators with the right lifetime and to delegate the execution to our code. In essence the servlet becomes one big factory and object look up. It is still untestable as ever, but at least there is no logic to test there. Since the nature of the factories is that they either work or they blow up spectacularly.

→ 9 CommentsTags: Uncategorized

Collaborator vs. the Factory

posted on March 30th, 2009 ·

by Miško Hevery

I have already hinted that your code should either be in the business of doing business logic or in the business of instantiating and wiring other objects together. What this effectively means is that your either have classes with ifs and loops (your business logic) or you have classes with new operators (your factories). Now at this point many people assume that they will need a factory for each class which will double the number of classes. But in practice you only need one factory class each time you cross an object lifetime. For example most web application, this implies that you have a factory for the application lifetime objects and than a factory for all af the request lifetime objects. More specifically one request lifetime factory for each servlet we have, since a servlet is long lived and we need a request lived object (we are crossing the boundary). Let’s look at an example of a LoginServlet.


The problem with the LoginServlet is that it is of wrong lifetime. A servlet is application lifetime object or a singleton. This means that we can not store any request level information in the servlet. Most people solve this problem by passing all of the request lifetime information through the stack to all of the different methods. However I thing that the responsibility of the servlet is to create a request lifetime object graph and than pass the execution to it. By creating a request scope object graph we are free to store the data in the class fields rather than being forced to pass them around on the stack. The responsibility of the LoginServlet is to create a LoginPage, it is a factory.

To allow the removal of the new operators from our business logic classes, we need to ask for our collaborators instead of making them. This means that each class only knows about other classes with which it is in direct contact and which it needs to get its job done. In our example the LoginPage would ask for AuditRecord and Authenticator in its constructor. Similarly the Auhenticator class would ask for Database, Captcha and AuditRecord as its collaborators. Finally the Database would ask for AuditRecord.

But how do we get the right information to the right location, or to put it differently, how do I get information to the database object without the Authenticator knowing, since the Authenticator is in the middle? The trick lies that the view of the world from the factory is different than the view from the collaborator.

Each collaborator only knows about its direct dependencies, as depicted by the arrow pointing to the right. And that is a good thing since it makes code reusable and it prevents any one class from knowing too much.

Now, let’s look at the factory. When the factory calls a new on the Login Page it must satisfy two dependencies: AuditRecord and the Authenticator. To make an Authenticator we must first instantiate a Database, Captcha and AuditRecord. However, we need to make sure that the AuditRecord in the Authenticator and in LoginPage is same instance, so we simply reuse it. Here is how it looks like in the code form:

AuditRecord audit = new AuditRecord();
Database database = new Database(audit);
Captcha captcha = new Captcha();
Authenticator authenticator =
    new Authenticator(database, captcha, audit);
LoginPage = new LoginPage(audit, authenticator);

What I find interesting is how different the code looks from the two points of view. The collaborators only know about its direct dependecies and the factories know about everything, and that is a good thing. Because the factories know about all of the objects in the graph they can easily make sure that everyone gets the same instance of the AuditRecord. In other words the factory can easily enforce that AuditRecord is a singleton without having to rely on a global variable. It also means that the factory can deliver the information to any one object without anyone else knowing about the information unnecessarily. For example if the AuditRecord needs to know the the HTTP cookie than the factory can inject the cookie into the AuditRecord without effecting any of the layers in between, namely the Authenticator and Database.

→ 11 CommentsTags: Uncategorized

Design for Testability and “Domain-Driven Design”

posted on March 16th, 2009 ·

Dave Gladfelter has written a great question which I think a lot of people may be asking an therefore I am sharing the letter with the answers here…

Misko,Thanks for all your interesting posts on testability.  I’ve been using DI and other techniques for some time for both testability and for maintainability and readability, but you’ve helped me understand some subtleties that I think will really help me write better code.

I have a question about your distinction between “newable”, value classes and “injectable” or “service” classes.

Domain-Driven_Design by Eric Evans divides classes/objects into basically 3 categories, SERVICE objects, ENTITY objects and VALUE OBJECTS.  VALUE OBJECTS are leaf classes like string classes and are obviously “newable”.  SERVICES represent external infrastructure, they don’t model domain state, and they tend to be singletons.  This makes them very similar to injectable objects.  My main concern is with ENTITY objects.  ENTITY objects in Eric’s methodology represent domain concepts that have specific lifetimes and identity.  Eric is primarily focused on enterprise/database style applications where the primary concern is data integrity, so the concept of the ENTITY is key to his modeling technique.

I have not read his book, so don’t take my comments as authority. Entity objects to me are newables, sort off.. First off they ore not injectable since you can’t say injector.getInstance(CreditCard.class). the injector simply does not have enough information to create one (Specifically, it is missing the ID). But you could say injector.getInstance(HibernateSession.class).get(CreditCard.class, 123). This will fetch the factory, which will fetch the CreditCard from the database by ID. Now to keep to things testable, I want to make sure that I can create CreditCard in my test without a database. So in my test it will be important that I can say new CreditCard(), otherwise I will have to constantly inject mocks into the credit card processor in my tests. Further more, if you are using ORM layer such as Hibernate, hibernate can’t inject anything into the CreditCard and it will try to persist any services on it. The reason I say sort of, is because in my code i will not just new one up, i will fetch it from the factory, but that is not the same as fully injectable.
The domains I’m working in at present are more functional / operational and aren’t concerned with identity, so I haven’t had an opportunity to put Eric’s methodology through the wringer yet to see what leaks out.  After reading your articles I am now confused about how to fit ENTITY’s into the compelling design-for-test methodology you’re advocating.

In your post “Writing Testable Code”, you say that a CreditCard class would tend to be a value object.  In Eric Evan’s methodology, I would think it would be an ENTITY.  I get the impression you advocate using value objects to hold domain data.  This would make maintaining domain-dictated identity and lifetimes hard, since value objects are newable, often copyable, and generally not too concerned with lifetime or identity.

Whether you call it Value or Entity, I think is irrelevant to the point I am trying to make. The CreditCard is an Entity since it has on ID and is persistable, but it is not a service. My definition of newable simply accounts for anything which is not a injectable hence a  service, Entities included.
I get the impression you are okay with treating domain data as dumb data which service objects manipulate based on the application domain logic.  In my mind, this creates an impedance mismatch between the object hierarchy and the domain under modeling.  I’ve always thought it a good rule of thumb to place an operation on the class whose state is most queried/modified by the operation.  In the case of processing a credit card transaction, it would be the credit card that is most affected by the transaction, not the credit card transaction processor service, and it would therefore be natural to place the operation on the credit card object.  The card would still need to collaborate with such a service for aspect-oriented binding for services such as fraud prevention, but it would be the credit card’s responsibility to form the messages and operations that comprise a credit card transaction and to pass them to the appropriate players.
I agree that the method should have affinity to the class which is most affected by it, in this case it would be CreditCard. But here is the real question of testability. If the method ‘charge’ is on CreditCard, how does it get a hold of CreditCardProcessor? Globals/Singletons are out of the questions, which leaves us with constructor or a parameter on the charge method. Constructor is out since that would interfere with the persistence layer (Hibernate would either try to persist the CreditCardProcessor or it will not be able to instantiate a new one from the database.) This leaves us with charge method taking a parameter to CreditCardProcessor. If you do that than you are all set form the testability point of view and you can have your business logic on the domain/entity/value class. The important thing to remember is that CreditCard can not have a field reference (it can only have a stack reference) to any services since that will interfere with the serialization / de-serialization process. It is not as important as where the charge method lives as which instance has reference to which other instances. Again, CreditCard can not have a field reference to CreditCardProcessor or it will interfere with persistent layer.
So, if I understand Eric’s approach properly and if he were trying to design for testability as well, I think he would advocate creating the credit card with a factory that would tie it to whatever services its various methods would need, and internal fields would be set during construction-time in the factory.  The credit card would then use internal logic to determine what messages to send to the services to respond to application requests (Charge transaction, generate monthly late notice batch script, etc.)
I would be against this approach as it would give CreditCard field reference to CreditCardProcessor as pointed out above and would require to write a custom factory for each persistable entity, the factory would than have to inject additional fields. I prefer hibernate approach where hibernate setter injects the state to CreditCard and persist all of the fields. Having both persistable and non-persistable fields smells of mixing of concerns. It is not the responsibility of CreditCard to know about the CreditCardProcessor. As a matter of fact I can imagine lots of scenarios where I have different CreditCardProcessor instances. Lets say you have online and offline CreditCardProcessor and at runtime you want to chose one depending on the availability of internet connection. Having the CreditCard know about the CreditCardProcessor would be a liability.
If I understand your methodology, there would be several global credit card servicing objects with the business logic for the various operations, and the application would pass dumb value objects to those services as needed to fulfill requests.
I never said dumb. OO says that behavior should live with the data. In this case it is perfectly fine to have the behavior of charging on the data (CreditCard) just make sure that CreditCardProcessor reference comes from the stack. But lets go to a real world for a second. Have you ever seen a CreditCard which knew how to charge itself? I have not. But I have seen a lot of CreditCardProcessors which when you punched in amount and slide the card through have made me poorer. So perhaps the charge should be with the service. :-) From a testability it makes no difference thought.
Now, imagine one logical credit card operation required several orthogonal services to complete.  Where would the business logic for that operation live?  Would there be yet another service object responsible for coordinating subordinate service objects?  What if one of the operations failed and the transaction needs to be rolled back.  Who is responsible for coordinating this?  Following Eric Evan’s methodology, the credit card would have all the information and logic needed to keep track of these higher-level concerns and would use the services as needed to create a valid application state even in the face of failures (the strong exception guarantee.)  The credit card would not allow multiple simultaneous operations to create a race condition in multithreaded environments because it would be simple to add locking to the operations on the credit card class.  In the test-driven model you describe, who would be responsible for detecting multiple simultaneous operations on the same card?   If a service had to do it, then it would have to maintain internal state corresponding to all the active credit cards in the system to detect such conditions, which would be duplicative and would decrease data coherence in the system.  You couldn’t put locking on the value-object-CreditCard class because it could have been copied (or deserialized multiple times) and therefore there would be no connection between the domain concept of serialization of transactions and the behavior of multiple credit card value objects with their own mutexes.
I have always let Hibernate deal with these issues. I fees strongly that CreditCard should be unaware about transactions, locks, etc. Look in your wallet, does your CreditCard know about any of these? Yet our financial system works just fine, (well maybe not if you read the news, but it is not for lack of transactions.) Hibernate solves your problem very simply. It creates two copies of the CreditCards. One for itself (private) and one for you (public). The CreditCard has an additional field version which Hibernate uses for locks. When hibernate commits it compares public and private versions to see if anything is dirty, if it is it than compares the version number with the one in the database. If versions match, than the version is incremented and data is committed, your public copy becomes stale (versions don’t match) and you need nod worry about someone keeping a reference to it accidently across the transactions. If versions do not match the database is rolledback and exception is thrown.
If you place all of these responsibilities onto the CreditCard, the system will be hard to test, not because you violated some injectable vs new rule, but because you violated single responsibility principle and you will be in mocking hell trying to instantiate it.
Are you familiar with this book?  Do you see its design methodology as being compatible with design for testability?  If so, how do you map the concepts in the two methodologies?


Dave Gladfelter

Hope this helps…
A day later I got a response form dave which I think is worth sharing…
Hi Misko,

Sorry in advance for another long message.  There aren’t any questions in it, and it is purely for your benefit, so feel free to read it whenever or never.  I’ve been thinking about your comments and I reviewed some key sections of Evan’s book.  I think there is not as much of a conflict as I thought.  It is remarkable to me that the testable design methodology and the domain-driven design methodology are so compatible since they serve somewhat differing goals.

Anyway, I think I got hung up on “newable” as meaning “value object”.  Entities need to be aware of their external, long-lived identities, but I think it is okay for the purposes of testability to make them newable.  I think it would be bad for anyone other than a “repository” (Eric’s term for a persistent-storage-backed factory) to create a credit card object.  Except during testing!  ;-)

Also, Eric does anticipate that some services will peform purely domain operations.  He agrees with you that keeping the set of operations on entities relatively uncluttered is crucial.  Some domain operations are simply defined by a set of procedural business rules, and they belong in a stateless service.

I was initially confused at how newable entities would get re-serialized.  At first, it seemed to me, since one doesn’t want (usually domain-state-free) services holding references to domain objects, and one doesn’t want domain objects holding references to services, that the only way to commit a transaction would be to have a method call that spans every transaction.

If an entity becomes unreachable from all threads in the process, then it will be unable to commit because it will not have access to its repository and there is no other object that can give it access to the repository, since no object has a reference to it other than the GC.  This means that for a testable, domain-driven system, either:

1. All “write” operations need to occur within the context of at least one, continuous thread of execution.
2. There must be some injectable service that needs to hold references to domain objects that are in-use.

The first choice is not scalable and the second choice violates the literal definition of Eric Evan’s definition of a SERVICE (“A SERVICE is an operation offered as an interface that stands alone in the model, without encapsulating state, as ENTITIES and VALUE OBJECTS do.”). However, since moving transaction state from the stack to the heap is arguably just a change in execution strategy for performance reasons, I guess I could argue that the spirit of Evan’s methodology is not violated because a service that holds suspended / waiting transactions could arguably be said to simply be executing those transactions temporarily off-thread. Modern OO libraries even have such services pre-defined for just this purpose.

Anyway, thanks for your help, After hearing from you and thinking a bit more about this, I think the two techniques actually match up incredibly well.  I do recommend the book if you get a chance, and I would look forward to reading about your thoughts on it in your blog posts.


Dave Gladfelter

→ 5 CommentsTags: Uncategorized

Guide to testability is now downloadable

posted on March 9th, 2009 ·

Guide to testability is now downloadable thanks to Blaine R Southam who has turned it into a pdf book.

Permanent link can be found from this page:

→ 5 CommentsTags: Uncategorized

Constructor Injection vs. Setter Injection

posted on February 19th, 2009 ·

by Miško Hevery

There seems to be two camps in dependency-injection: (1) The constructor-injection camp and (2) the setter-injection camp. Historically the setter-injection camp come from spring, whereas constructor-injection camp are from pico-container and GUICE. But lets leave the history behind and explore the differences in the strategies.


The basic-ideas is that you have a no argument-constructor which creates the object with “reasonable-defaults” . The user of the object can then call setters on the object to override the collaborators of the object in order to wire the object graph together or to replace the key collaborators with test-doubles.


The basic idea with constructor-injection is that the object has no defaults and instead you have a single constructor where all of the collaborators and values need to be supplied before you can instantiate the object.

At first it may seem that setter injection is preferred since you have no argument constructors which will make it easy for you to create the object in production and test. However, there is one non-obvious benefit with constructor injection, which in my opinion makes it a winner. Constructor-injection enforces the order of initialization and prevents circular dependencies. With setter-injection it is not clear in which order things need to be instantiated and when the wiring is done. In a typical application there may be hundreds of collaborators with at least as many setter calls to wire them together. It is easy to miss a few setter calls when wiring the application together. On the other hand constructor-injection automatically enforces the order and completeness of the instantiated. Furthermore, when the last object is instantiated the wiring phase of your application is completed. This further allows me to set the collaborators as final which makes the code easier to comprehend if you know a given field will not change during the lifetime of the application.

Let’s look at an example as to how we would instantiate a CreditCardProcessor.

CreditCardProcessor processor 
        = new CreditCardProcessor();

Great I have instantiated CreditCardProcessor, but is that enough? No, I somehow need to know to call, setOfflineQueue(). This information is not necessarily obvious.

OfflineQueue queue = new OfflineQueue();
CreditCardProcessor processor 
        = new CreditCardProcessor();

Ok I have instantiated the OfflineQueue and remember to set the queue as a collaborator of the processor, but am I done? No, you need to set the database to both the queue and the processor.

Database db = new Database();
OfflineQueue queue = new OfflineQueue();
CreditCardProcessor processor 
        = new CreditCardProcessor();

But wait, you are not done you need to set the Username, password and the URL on the database.

Database db = new Database();
OfflineQueue queue = new OfflineQueue();
CreditCardProcessor processor 
        = new CreditCardProcessor();

Ok, am I done now? I think so, but how do I know for sure? I know a framework will take care of it, but what if I am in a language where there is no framework, then what?

Ok, now let’s see how much easier this will be in the constructor-injection. Lets instantiate CreditCardPrecossor.

CreditCardProcessor processor 
        = new CreditCardProcessor(?queue?, ?db?);

Notice we are not done yet since CreditCardProcessor needs a queue and a database, so lets make those.

Database db = new Database(
        "username", "password", "jdbc:....");
OfflineQueue queue = new OfflineQueue(db);
CreditCardProcessor processor 
        = new CreditCardProcessor(queue, db);

Ok, every constructor parameter is accounted for, therefore we are done. No framework needed, to tell us that we are done. As an added bonus the code will not even compile if all of the constructor arguments are not satisfied. It is also not possible to instantiate things in the wrong order. You must instantiate Database before the OfflineQueue, since otherwise you could not make the compiler happy. I personally find the constructor-injection much easier to use and the code is much easier to read and understand.

Recently, I was building a Flex application and using the Model-View-Controller. Flex XML markup requires that components must have no argument constructors, therefore I was left with setter-injection as the only way to do dependency injection. After several views I was having hard time to keep all of the pieces wired together properly, I was constantly forgetting to wire things together. This made the debugging hard since the application appeared to be wired together (as there are reasonable defaults for your collaborators)  but the collaborators were of wrong instances and therefor the application was not behaving just right. To solve the issue, I was forced to abandon the  Flex XML as a way to instantiate the application so that I can start using the constructor-injection and these issues went away.

→ 31 CommentsTags: Uncategorized