by Miško Hevery

Dependency injection asks us to separate the new operators from the application logic. This separation forces your code to have factories which are responsible for wiring your application together. However, better than writing factories, we want to use automatic dependency injection such as GUICE to do the wiring for us. But can DI really save us from all of the new operators?

Lets look at two extremes. Say you have a class MusicPlayer which needs to get a hold of AudioDevice. Here we want to use DI and ask for the AudioDevice in the constructor of the MusicPlayer. This will allow us to inject a test friendly AudioDevice which we can use to assert that correct sound is coming out of our MusicPlayer. If we were to use the new operator to instantiate the BuiltInSpeakerAudioDevice we would have hard time testing. So lets call objects such as AudioDevice or MusicPlayer "Injectables." Injectables are objects which you will ask for in the constructors and expect the DI framework to supply.

Now, lets look at the other extreme. Suppose you have primitive "int" but you want to auto-box it into an "Integer" the simplest thing is to call new Integer(5) and we are done. But if DI is the new "new" why are we calling the new in-line? Will this hurt our testing? Turns out that DI frameworks can't really give you the Integer you are looking for since it does not know which Integer you are referring to. This is a bit of a toy example so lets look at something more complex.

Lets say the user entered the email address into the log-in box and you need to call new Email("a@b.com"). Is that OK, or should we ask for the Email in our constructor. Again, the DI framework has no way of supplying you with the Email since it first needs to get a hold of a String where the email is. And there are a lot of Strings to chose from. As you can see there are a lot of objects out there which DI framework will never be able to supply. Lets call these "Newables" since you will be forced to call new on them manually.

First, lets lay down some ground rules. An Injectable class can ask for other Injectables in its constructor. (Sometimes I refer to Injectables as Service Objects, but that term is overloaded.) Injectables tend to have interfaces since chances are we may have to replace them with an implementation friendly to testing. However, Injectable can never ask for a non-Injectable (Newable) in its constructor. This is because DI framework does not know how to produce a Newable. Here are some examples of classes I would expect to get from my DI framework: CreditCardProcessor, MusicPlayer, MailSender, OfflineQueue. Similarly Newables can ask for other Newables in their constructor, but not for Injectables (Sometimes I refer to Newables as Value Object, but again, the term is overloaded). Some examples of Newables are: Email, MailMessage, User, CreditCard, Song. If you keep this distinctions your code will be easy to test and work with. If you break this rule your code will be hard to test.

Lets look at an example of a MusicPlayer and a Song

class Song {
 Song(String name, byte[] content);
}
class MusicPlayer {
 @Injectable
 MusicPlayer(AudioDevice device);
 play(Song song);
}

Notice that Song only asks for objects which are Newables. This makes it very easy to construct a Song in a test. Music player is fully Injectable, and so is its argument the AudioDevice, therefore, it can be gotten from DI framework.

Now lets see what happens if the MusicPlayer breaks the rule and asks for Newable in its constructor.

class Song {
 String name;
 byte[] content;
 Song(String name, byte[] content);
}
class MusicPlayer {
 AudioDevice device;
 Song song;
 @Injectable
 MusicPlayer(AudioDevice device, Song song);
 play();
}

Here the Song is still Newable and it is easy to construct in your test or in your code. The MusicPlayer is the problem. If you ask DI framework for MusicPlayer it will fail, since the DI framework will not know which Song you are referring to. Most people new to DI frameworks rarely make this mistake since it is so easy to see: your code will not run.

Now lets see what happens if the Song breaks the rule and ask for Injectable in its constructor.

class MusicPlayer {
 AudioDevice device;
 @Injectable
 MusicPlayer(AudioDevice device);
}
class Song {
 String name;
 byte[] content;
 MusicPlayer palyer;
 Song(String name, byte[] content, MusicPlayer player);
 play();
}
class SongReader {
 MusicPlayer player
 @Injectable
 SongReader(MusicPlayer player) {
   this.player = player;
 }
 Song read(File file) {
   return new Song(file.getName(),
                   readBytes(file),
                   player);
 }
}

At first the world looks OK. But think about how the Songs will get created. Presumably the songs are stored on a disk and so we will need a SongReader. The SongReader will have to ask for MusicPlayer so that when it calls the new on a Song it can satisfy the dependencies of Song on MusicPlayer. See anything wrong here? Why in the world does SongReader need to know about the MusicPlayer. This is a violation of Law of Demeter. The SongReader does not need to know about MusicPlayer. You can tell since SongReader does not call any method on the MusicPlayer. It only knows about the MusicPlayer because the Song has violated the Newable/Injectable separation. The SongReader pays the price for a mistake in Song. Since the place where the mistake is made and where the pain is felt are not the same this mistake is very subtle and hard to diagnose. It also means that a lot of people make this mistake.

Now from the testing point of view this is a real pain. Suppose you have a SongWriter and you want to verify that it correctly serializes the Song to disk. Why do you have to create a MockMusicPlayer so that you can pass it into a Song so that you can pass it into the SongWritter. Why is MusicPlayer in the picture? Lets look at it from a different angle. Song is something you may want to serialize, and simplest way to do that is to use Java serialization. This will serialize not only the Song but also the MusicPlayer and the AudioDevice. Neither MusicPlayer nor the AudioDevice need to be serialized. As you can see a subtle change makes a whole lot of difference in the easy of testability.

As you can see the code is easiest to work with if we keep these two kinds objects distinct. If you mix them your code will be hard to test. Newables are objects which are at the end of your application object graph. Newables may depend on other Newables as in CreditCard may depend on Address which may depend on a City but these things are leafs of the application graph. Since they are leafs, and they don't talk to any external services (external services are Injectables) there is no need to mock them. Nothing behaves more like a String like than a String. Why would I mock User if I can just new User, Why mock any of these: Email, MailMessage, User, CreditCard, Song? Just call new and be done with it.

Now here is something very subtle. It is OK for Newable to know about Injectable. What is not OK is for the Newable to have a field reference to Injectable. In other words it is OK for Song to know about MusicPlayer. For example it is OK for an Injectable MusicPlayer to be passed in through the stack to a Newable Song. This is because the stack passing is independent of DI framework. As in this example:

class Song {
 Song(String name, byte[] content);
 boolean isPlayable(MusicPlayer player);
}

The problem becomes when the Song has a field reference to MusicPlayer. Field references are set through the constructor which will force a Law of Demeter violation for the caller and we will have hard time to test.

Sometimes you need to test client-side JavaScript code that uses setTimeout() to do some work in the future. jsUnit contains the Clock.tick() method, which simulates time passing without causing the test to sleep.
For example, this function will set up some callbacks to update a status message over the course of four seconds:

function showProgress(status) {
  status.message = "Loading";
  for (var time = 1000; time <= 3000; time+= 1000) {
    // Append a '.' to the message every second for 3 secs.
    setTimeout(function() {
      status.message += ".";
    }, time);
  }
  setTimeout(function() {
    // Special case for the 4th second.
    status.message = "Done";
  }, 4000);
}

The jsUnit test for this function would look like this:

function testUpdatesStatusMessageOverFourSeconds() {
  Clock.reset(); // Clear any existing timeout functions on the event queue.
  var status = {};
  showProgress(status); // Call our function.

  assertEquals("Loading", status.message);

  Clock.tick(2000); // Call any functions on the event queue that have been
                    // scheduled for the first two seconds.
  assertEquals("Loading..", status.message);

  Clock.tick(2000); // Same thing again, for the next two seconds.
  assertEquals("Done", status.message);
}

This test will run very quickly - it does not require four seconds to run.

Clock supports the functions setTimeout(), setInterval(), clearTimeout(), and clearInterval(). The Clock object is defined in jsUnitMockTimeout.js, which is in the same directory as jsUnitCore.js.

Remember to download this episode of Testing on the Toilet and post it in your office.

Posted by Jessica Tomechak, Test Engineering Team

Julian Harty, one of our senior test engineers, is presenting a keynote at the STARWEST conference today (Wednesday, October 1) on Six Thinking Hats for Software Testers. Expanding on the Thinking Hats concept, originated many years ago by Edward De Bono and used by large numbers of people and various types of businesses, Julian's talk will add his experience and views about how Thinking Hats can be used in software testing. At Google, we have found it delivers breakthroughs in the short term and great results in the longer term -- one Googler called it the "universal unblocker."

For those of you unable to attend the conference, a video recording will be available. Julian has also written an article on this topic to appear in Better Software magazine within the next few months.

by Miško Hevery

We talked about how it is important to separate the new operators from the application logic. This separation forces your code to have factories which are responsible for wiring your application together. By separating these responsibilities the tests can always wire together a subset of an application with key components replaced for friendlies making testing easier and more focused.

Let's look at a sample factory

class CarFactory {

Car create() {

  return new Car(

        new EngineCompartment(

              new Engine(),

                new Door(new PowerWindow()),

              new Door(new PowerWindow()),

              new PowerSeat(), new PowerSeat()                new ManualTransmission(),

              new PowerSteering(),

              new Battery()

           ),

        new Cabin(

              new Door(new PowerWindow()),

              new Door(new PowerWindow()),

              new PowerSeat(), new PowerSeat()

          ),

       Arrays.asList(

            new Wheel(new Tire(), new Rim()),

            new Wheel(new Tire(), new Rim()),

            new Wheel(new Tire(), new Rim()),

            new Wheel(new Tire(), new Rim())

          )

     );

}

}

This factory builds a car. The first thing to notice is that all of the new operators are here (If you were to look inside each of the classes it would be devoid of "new"s). The second thing to notice is a complete lack of logic (no loops or conditions). And thirdly, your application behavior is controlled by the way the classes are wired together. If I wanted a automatic-transmission car, all I would have to do is to wire the classes differently. The wiring responsibility is in the factory class not with the application logic.

But why do we need to tell the JVM how to wire these Classes together? Is it not self obvious? Just look at the constructors of these classes:

Car(EngineCompartment ec, Cabin c, List ws);

EngineCompartment(Engine e, Transmission t,

            Steering s, Battery b);

Cabin(Door driverDoor, Door passengerDoor,

            Seat driverSeat, Seat passengerSeat);

Engine(float dissplacement, int pistonCount);

Battery(float voltage);

Door(Window window);

                new Door(new PowerWindow()),

              new Door(new PowerWindow()),

              new PowerSeat(), new PowerSeat()PowerWindow() implements Window;

PowerSeat() implements Seat;

Wheel(Tire tire, Rim rim);

...

Imagine you could just ask for things. Lets start simple and look at the Wheel. The constructor of Wheel needs a Tire and Rim. So when we ask for a Wheel it should be obvious that we want new Wheel(new Tire(), new Rim()). Why do we need to make this explicit in our factory? Lets build a framework from which we can ask for a class and it returns an instance of that class. So in our case if we ask for getInstance(Wheel.class) it returns a new Wheel(new Tire(), new Rim()). Now a framework like this is easy to build since all we need to do is look at the constructor and recursively try to instantiate the objects until all recursive constructors are satisfied.

But things are a bit more complicated than that. What if we ask for Cabin, as in getInstance(Cabin.class)? Well Cabin needs two Doors and two Seats, but Seat is an interface so we have to make a decision: What subclass of Seat should we instantiate? To help our framework make that decision, somewhere we will add a bind method such as bind(Seat.class, PowerSeat.class). Great! Now when we call getInstance(Seat.class) the framework returns new PowerSeat(). Similarly, we will have to call bind(Window.class, PowerWindow.class). Now we can call getInstance(Cabin.class) and the framework will return new Cabin(new Door(new PowerWindow()), new Door(new PowerWindow()), new PowerSeat(), new PowerSeat()).

Notice that closer a class you ask for is to the root (Car in this case), the more work will the framework do for us. So ideally we just want to ask for the root object, Car. Calling getInstance(Car.class) will cause the framework to do all of the work originally in our factory.

As you can see a framework which will call the new operators on your behalf is very useful. This is because you only have to ask for the root object (in our case the Car) and the framework will build the whole object graph on your behalf. This kinds of frameworks are called Automatic Dependency Injection frameworks and there are few of them our there. Namely GUICE, PicoContainer, and Spring.

Since I know most about GUICE, The above example can be rewritten in GUICE like this:

class CarModule extends AbstractModule() {

public void bind() {

  bind(Seat.class, PowerSeat.class);

  bind(Seat.class, PowerSeat.class);

  bind(Transmission.class, ManualTransmission.class);

  // maybe use a provider method?(jwolter)

  // maybe explain the need for different wheels, so use a Provider;

  bind(new TypeLiteral>(){})

    .toProvider(new Provider>(){

      @Inject Provider wp;

      List get() {

        return Array.asList(wp.get(), wp.get(),

                            wp.get(), wp.get());

      }

    });

}



// or, what I think is simpler and clearer

@Provides

List provideWheels(Provider wp) {

  return Array.asList(wp.get(), wp.get()

                      wp.get(), wp.get());

}

}

// Then somewhere create your application, using the injector only

//   once, for the root object.

Injector injector = Guice.createInjector(new CarModule());

Car car = injector.getInstance(Car.class);

As you can see Automatic Dependency Injection frameworks can do a lot of things for you. Namely, that you don't have to worry about writing the factories. You simply declare dependencies, and write your application logic. As needed, you ask for your dependencies in a constructor and let the framework resolve all of them for you. You move the responsibility of calling the new operator to the framework. The DI-framework is your new "new". Now DI-frameworks can do lot of other things, which are beyond the scope of this article, such as manage object lifetimes, enforce singletons (in a good way, see: Root Cause of Singletons and Singletons are Pathological Liars) and manage different configurations of your application such as production vs development server.

For a more real life example of a Guice Module see: CalculatorServerModule.java

Also, the curious may wonder why a Provider is injected into the provider method for List<Wheel>. This is because our 4 wheeled car needs to have different wheels. If we injected a single wheel, it would be assigned as the same wheel on all 4 positions. Providers, when used without any explicit scopes will return a new instance every time get() is called on them.

[A light hearted episode this week... but still with a serious message. Enjoy. -Dave]

HALP! Mah unit tests be doin' too much I/O! Testin' this lil' codes uses MOAR RESOURCES!

GIMME lol_io LIKE LOLIO

SO IM LIKE PROCESSIN WIT DATAZ OK?
  GIMME EACH BUCKET IN UR DATAZ OK?
    BUCKET OWN FUBARRED?
      N CAN HAS NONE
    NOPE?
      N CAN HAS 1
  KTHXBYE N

IZ __name__ KINDA LIKE “__main__”?
  UR PROCESSIN WIT LOLIO OWN GET_SOME_DATAZ
  BTW, GET_SOME_DATAZ USES UR INTERNETS LOL

Oh NOES! Usin' internets in ur unit testz? Don't clog the tubes! Is not big truck! Mock the LOLIO thingy. No moar tubes!

GIMME mock_lol_io LIKE LOLIO

BTW, GIMME THING TO TEST
BTW, TEST THE THING NOW KTHX

Now ur test runs fast! You can use mock_lol_io for killin' nondeterminism, too like for exceptions n stuff. Is fun, makes ur code execute pathz it nevar seen b4. Wit dis, you can see wut happens when theres a OH NOES like the tubez bein clogged.

BTW, SOMETIMES THEY BE CALLIN DIS DEPENDENCY INJECTION ROFL

BTW, YOU CAN UZE MOCKZ N STUF FER DIS LOOK:

IN MAI library GIMME mock_filesystem LIKE LOL_FAKE_FILEYSTEM

BTW, NOW U CAN USE LOL_FAKE_FILESYSTEM TO MAKE FAKE FILEZ IN MEMORY N STUFF
BTW, IS FASTER THAN OPENIN FILEZ ON TEST SERVAR

Now U know the sekrit for faster tests. Shh, don't tell Microsawft or the Yahew. They might be in our base, stealin our tech!

KTHXBYE!

Remember to download this episode of Testing on the Toilet and post it in your office.

Posted by Marc Kaplan, Test Engineering Manager

When looking at whether to check a new change in, there are several testing-related questions that can be asked, which at least include:
1. Does the new functionality work?
2. Did this change break existing functionality?
3. What is the performance impact of this change?

We can either answer these questions before we check things in, or after. We found that we can save a lot of time and effort in trying to do detective work and track bad changes down if we do this before check in to the depot. In most teams developers kick off the tests before they check anything in, but in case somebody forgets, or doesn't run all of the relevant tests, a more automated system was desired. So we have what we call presubmit systems at Google to run all of the relevant tests in an automated fashion pre-checkin, without the developer doing anything before the code is actually checked in. The idea behind this is that once the code is finished being written there are minutes or hours before it's checked in while it's being reviewed via the Google code review process (more info on that at Guido's Tech Talk on Mondrian). So we have taken advantage of this time by running tests via the presubmit system that finds all of the tests that are relevant to the change, runs the tests, and reports the results.

Most of the work around presubmit at Google has been looking at functionality (question 1, and 2 above), however in the GFS Team where we are making a lot of performance-related changes we wondered whether a performance presubmit system would be possible. So recently we developed such a system and have begun to start using it. Basically a hook was added to the code review process such that once a developer sends out a change for review, and automated performance test is started via the GFS Performance Testing Tool that we previously described on another Testing Blog post. Once two runs of the performance test are finished, they are compared against a known-good baseline that gets automatically created at the beginning of each week, and a comparison graph is generated and e-mailed to the user submitting the CL. So now we know, prior to checking some code in if it has some unexpected hit to performance. Additionally, now when a developer wants to make a change they think will improve performance they don't need to do anything other than a normal code review which will trigger an automatic performance test to see if they got the performance bump they were hoping for.

Example of a performance presubmit report:

I've seen many companies and projects where performance testing is cumbersome and not run very often until near release date. As you might expect, this is very problematic because once you find a performance bug you have to go back through all of the changes and try to narrow it down, and many times it's simply not that easy. Doing the performance testing early, and often helps narrow things down, but we've found that it's even better to make sure that these performance regressions never creep into the code with pre-check in performance testing. Certainly you should still do a final performance test once this code is frozen, but with the presubmit performance testing system in place you are essentially certain that the performance will be as good as you expect it to be.

The Google Maps API is one of our most popular developer products here at Google, and is also one of the trickiest to test because of its visual nature and diverse uses. It has to go through the standard backend and JsUnit testing, but then also through a suite of Selenium tests to make sure that DOM elements are positioned correctly, mouse events are triggered correctly, and even tests to address random bugs like Issue 517, where IE errored out when an implicitly closed base tag was used in the developer's HTML. And to top it off, all those tests must pass in every one of the API's supported browsers.

So, we decided to open source our selenium test suite so that developers could see the kind of integration tests we're currently running, and could even contribute their own tests that test specific functionality or an order of operations used on their site. What better way to make sure your site works with our API than contribute a test to make sure of it?

You can read more about the suite on our blog, peruse through our tests, and if you're a Maps API developer yourself, send us a test or two!

By Miško Hevery
(the other title: Your Application has a Wiring Problem)

In My main() Method Is Better Than Yours we looked into what a main() method should look like. There we introduced a clear separation between (1) the responsibility of constructing the object graph and (2) the responsibility of running the application. The reason that this separation is important was outlined in How to Think About the “new” Operator. So let us look at where have all of the new operators gone...

Before we go further I want you to visualize your application in your mind. Think of the components of your application as physical boxes which need to be wired together to work. The wires are the references one component has to another. In an ideal application you can change the behavior of the application just by wiring the components differently. For example instead of instantiating LDAPAuthenticator you instantiate KerberosAuthenticator and you wire the KerberosAuthenticator to appropriate components which need to know about Authenticator. That is the basic idea. By removing the new operators from the application logic you have separated the responsibility of wiring the components from the application logic, and this is highly desirable. So now the problem becomes, where have all the new operators gone?

First lets look at a manual wiring process. In the main() method we asked the ServerFactory to build us a Server (in our case a Jetty Web Server) Now, server needs to be wired together with servlets. The servlets, in turn, need to be wired with their services and so on. Notice that the factory bellow is full of "new" operators. We are new-ing the components and we are passing the references of one component to another to create the wiring. This is the instantiation and wiring activity I asked you to visualize above. (Full source):

  public Server buildServer() {
  Server server = new Server();

  SocketConnector socketConnector
       = new SocketConnector();
  socketConnector.setPort(8080);
  server.addConnector(socketConnector);

  new ServletBuilder(server)
    .addServlet("/calc", new CalculatorServlet(
                         new Calculator()))
    .addServlet("/time", new TimeServlet(
                         new Provider() {
      public Date get() {
        return new Date();
      }
    }));

  return server;
}

When I first suggest to people that application logic should not instantiate its own dependencies, I get two common objections which are myths:

1. "So now each class needs a factory, therefore I have twice as many classes!" Heavens No! Notice how our ServerFactory acted as a factory for many different classes. Looking at it I counted 7 or so classes which we instantiated in order to wire up our application. So it is not true that we have one to one correspondence. In theory you only need one Factory per object lifetime. You need one factory for all long-lived objects (your singletons) and one for all request-lifetime objects and so on. Now in practice we further split those by related concepts. (But that is a discussion for a separate blog article.) The important thing to realize is that: yes, you will have few more classes, but it will be no where close to doubling your load.


2. "If each object asks for its dependencies, than I will have to pass those dependencies through all of the callers. This will make it really hard to add new dependencies to the classes." The myth here is that call-graph and instantiation-graph are one and the same. We looked into this myth in Where have all the Singletons Gone. Notice that the Jetty server calls the TimeServlet which calls the Date. If the constructor of Date or TimeServlet all of a sudden needed a new argument it would not effect any of the callers. The only code which would have to change is factory class above. This is because we have isolated the instantiation/wiring problem into this factory class. So in reality this makes it easier to add dependencies not harder.

Now there are few important things to remember. Factories should have no logic! Just instantiation/wiring (so you will probably not have any conditionals or loops). I should be able to call the factory to create a server in a unit test without any access to the file-system, threads or any other expensive CPU or I/O operations. Factory creates the server, but does not run it. The other thing you want to keep in mind is that the wiring process is often controlled by the command line arguments. This makes is so that your application can behave differently depending what you pass in on a command line. The difference in behavior is not conditionals sprinkled throughout your code-base but rather a different way of wiring your application up.

Finally, here are few thoughts on my love/hate of Singletons (mentioned here and here) First a little review of singletons. A singleton with a lower case 's' is a good singleton and simply means a single instance of some class. A Singleton with an upper case 'S' is a design pattern which is a singleton (one instance of some class) with a global "instance" variable which makes it accessible from anywhere. It is the global instance variable which makes it globally accessible , which turns a singleton into a Singleton. So singleton is acceptable, and sometimes very helpful for a design, but Singleton relies on mutable global state, which inhibits testability and makes a brittle, hard to test design. Now notice that our factory created a whole bunch of singletons as in a single instance of something . Also notice how those singletons got explicitly passed into the services that needed them. So if you need a singleton you simply create a single instance of it in the factory and than pass that instance into all of the components which need them. There is no need for the global variable.

For example a common use of Singleton is for a DB connection pool. In our example you would simply instantiate a new DBConnectionPool class in the top-most factory (above) which is responsible for creating the long-lived objects. Now lets say that both CalculatorServlet and TimeServlet would need a connection pool. In that case we would simply pass the same instance of the DBConnectionPool into each of the places where it is needed. Notice we have a singleton (DBConnectionPool) but we don't have any global variables associated with that singleton.

  public Server buildServer() {
  Server server = new Server();

  SocketConnector socketConnector
       = new SocketConnector();
  socketConnector.setPort(8080);
  server.addConnector(socketConnector);

  DBConnectionPool pool = new DBConnectionPool();
  new ServletBuilder(server)
    .addServlet("/calc", new CalculatorServlet(
                         pool,
                         new Calculator()))
    .addServlet("/time", new TimeServlet(
                         pool,
                         new Provider() {
      public Date get() {
        return new Date();
      }
    }));

  return server;
}