by Miško Hevery

So you discovered dependency injection and GUICE and you are happily refactoring and writing new tests for you code until you come across this circular reference.

class A {
final B b;
A(B b){
  this.b = b;
}
}

class B {
final A a;
B(){
  this.a = new A(this);
}
}

+---------+      +---------+
|    A    |<-----|    B    | |         |      |         | |         |----->|         |
+---------+      +---------+

Hm, dependency injection says that you need to ask for your dependencies and so the resulting code will be:

class A {
final B b;
A(B b){
  this.b = b;
}
}

class B {
final A a;
B(A a){
  this.a = a;
}
}

But now we have a problem, we can't instantiate this (I know GUICE can through proxy, but it is not clean and it does not help us in tests). So the real problem in situation like this is mixing of concerns. One of the two objects is hiding another object C. Either A contains C or B contains C. To find out which one it is, list all of the methods in your class A and class B and. The shorter of the two lists is your hidden Class C.

+---------+      +---------+
|    A    |<-----|  B      | |         |      |  |  +-+ | |         |      |  +->|C| |
|         |------+---->| | |
|         |      |     +-+ |
+---------+      +---------+

Suppose B has the shorter list. We now extract all of the methods in B which are accessing the state of hidden C methods into a new object C like this:

                         +---------+
+---------+              |    B    |
|    A    |<-------------|         | |         |              |         | |         |    +---+     |         | |         |--->| C |<----|         | |         |    +---+     +---------+ +---------+ class C {  C(){  } }  class A {  final C c;  A(C c){    this.c = c;  } }  class B {  final A a;  final C c;  B(A a, C c){    this.a = a;    this.c = c;  } }

When you go through this exercise you will realize that the C was always an object in its own right but you have never thought about it that way, so the new code is actually better OO. From testing point of view you can now test each class in isolation.

To quell a lingering feeling of inadequacy, you took the time to build your own planetary death ray, a veritable rite of passage in the engineering profession. Congratulations. And you were feeling pretty proud until the following weekend, when you purchased the limited-edition Star Wars trilogy with Ewok commentary, and upon watching the Death Star destroy Alderaan, you realized that you had made a bad decision: Your planetary death ray has a blue laser, but green lasers look so much cooler. But it's not a simple matter of going down to Radio Shack to purchase a green laser that you can swap into your existing death ray. You're going to have to build another planetary death ray from the ground-up to have a green laser, which is fine by you because owning two death rays instead of one will only make the neighbors more jealous.

Both your planetary death rays should interoperate with a variety of other bed-wettingly awesome technology, so it's natural that they export the same Java API:

public interface PlanetaryDeathRay {
  public void aim(double xPosition, double yPosition);
  public boolean fire(); /* call this if she says the rebel
                            base is on Dantooine */
}

public class BlueLaserPlanetaryDeathRay
    implements PlanetaryDeathRay { /* implementation here */ }
public class GreenLaserPlanetaryDeathRay
    implements PlanetaryDeathRay { /* implementation here */ }

Testing both death rays is important so there are no major malfunctions, like destroying Omicron Persei VIII instead of Omicron Persei VII. You want to run the same tests against both implementations to ensure that they exhibit the same behavior – something you could easily do if you only once defined tests that run against any PlanetaryDeathRay implementation. Start by writing the following abstract class that extends junit.framework.TestCase:

public abstract class PlanetaryDeathRayTestCase
    extends TestCase {
  protected PlanetaryDeathRay deathRay;
  @Override protected void setUp() {
    deathRay = createDeathRay();
  }
  @Override protected void tearDown() {
    deathRay = null;
  }
  protected abstract PlanetaryDeathRay createDeathRay();
      /* create the PlanetaryDeathRay to test */

  public void testAim() {
    /* write implementation-independent tests here against
       deathRay.aim() */
  }
  public void testFire() {
    /* write implementation-independent tests here against
       deathRay.fire() */
  }
}

Note that the setUp method gets the particular PlanetaryDeathRay implementation to test from the abstract createDeathRay method. A subclass needs to implement only this method to create a complete test: the testAim and testFire methods it inherits will be part of the test when it runs:

public class BlueLaserPlanetaryDeathRayTest
    extends PlanetaryDeathRayTestCase {
  protected PlanetaryDeathRay createDeathRay() {
    return new BlueLaserPlanetaryDeathRay();
  }
}

You can easily add new tests to this class to test functionality specific to BlueLaserPlanetaryDeathRay.

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

by Miško Hevery, Jonathan Wolter, Russ Ruffer, Brad Cross, and lots of other test infected Googlers

This guide lists principles that will help you write impossible to tests code. Or, avoiding these techniques will help you write code that can be tested.

• Make Your Own Dependencies - Instantiate objects using new in the middle of methods, don't pass the object in. This is evil because whenever you new up an object inside a block of code and then use it, anyone that wants to test that code is also forced to use that concrete object you new'ed up. They can't "inject" a dummy, fake, or other mock in to simplify the behavior or make assertions about what you do to it.


• Heavy Duty Constructors - Make constructors that do lots of work in them. The more work you do in the constructor, the hard it is to create your object in a test fixture. And if your constructor can construct other things that are hard themselves to construct, that's even better! You want the transitive dependencies of every constructor to be enormous. Enormous is hard to get under test.


• Depend on Concrete Classes - Tie things down to concrete classes - avoid interfaces wherever possible. (They let people substitute the concrete classes you're using for their own classes which would implement the same contract in the interface or abstract class. Testing do-gooders might want to do this to get your code under a test harness - don't let them!)


• Conditional Slalom - Always, always, feel good when writing lengthy if branches and switch statements. These increase the number of possible execution paths that tests will need to cover when exercising the code under test. The higher the Cyclomatic complexity, the harder it is to test! When someone suggests to use polymorphism instead of conditionals, laugh at their thoughtfulness towards testing. Make the branching both deep and wide: if you're not consistently at least 5 conditionals deep, you're spoon feeding testable code to the TDD zealots.


• Depend on Large Context Objects - Pass around ginormous context objects (or small ones with hard to construct contents). These will reduce the clarity of methods [myMethod(Context ctx) is less clear than myMethod(User user, Label label)]. For testing, the context objects will need to be created, populated, and passed around.


• Use Statics - Statics, statics everywhere! They put a great big crunch in testability. They can't be mocked, and are a smell that you've got a method without a home. OO zealots will say that a static method is a sign that one of the parameters should own the method. But you're being 3v1L!


• Use More Statics - Statics are a really powerful tool to bring TDD Infected engineers to their knees. Static methods can't be overridden in a subclass (sometimes subclassing a class and overriding methods is a technique for testing). When you use static methods, they can't be mocked using mocking libraries (nixing another trick up the pro-testing engineer's sleeve).


• Use Global Flags - Why call a method explicitly? Just like L Ron Hubbard, use "mind over matter" to set a flag in one part of your code, in order to cause an effect in a totally different part of your application (it's even more fun when you do it concurrently in different threads!). The testers will go crazy trying to figure out why all of a sudden a conditional that was evaluating true one minute is all of a sudden evaluating to false.


• Use Singletons Everywhere - Why pass in a dependency and make it obvious when you can use a singleton? It's hard to set up a test that requires singletons, and the TDDers will be in for a world of hurt when all their tests depend on each other's state.


• Be Defensive - They're out to Get Your Code! - Defensively assert about the state of parameters passed in methods, constructors, and mid-method. If someone can pass in a null, you've left your guard down. You see, there are testing freaks out there that like to instantiate your object, or call a method under test and pass in nulls! Be aggressive in preventing this: rule your code with an iron fist! (And remember: it's not paranoia if they really are out to get you.)


• Use Primitives Wherever Possible - Instead of using a "cookie object," pass in primitives and do all the parsing you need, every time you need a value. Primitives make people work harder by having to parse and massage them to get the data out -- where objects are mockable (gasp) and nullable, and encapsulate state (who'd want to do that?)


• Look for Everything You Need - By Looking for things you are asserting your objects dominance as the object which knows where everything is. This will make the life of tester hard, since he will have to mimic the environment so that your code can get a hold of what it needs. And don't be afraid of how many objects you need to reach out to to, the more the harder it will be for test to mock them all out in unisin. If you are an InvoiceTaxCalculator, feel free to do things like: invoiceTaxCalculator.getUser().getDbManager().getCaRateTables().getSalesTaxRate(). Cover your ears when some testing weenie tells you about Dependency Injection, Law of Demeter, or not looking for things.


• Use static initializes - Do as much work as possible when your class is loaded. Testing nuts will be so frustrated when they find out just loading your class causes nasty stuff like network or file access.


• Couple functional code directly to the external systems it depends on If your product uses external systems such as a databases, file systems or a network, make sure your business logic is coded to reference as many low level implementation details of these systems as possible. This will prevent others from using your code in ways you don't intend, (like small tests that run in 2 ms instead of 5 minutes).


• Mix Object Lifecycles - Have long lived objects reference short lived objects. This confuses people as the long lived object references the short lived object still after it's no longer valid or alive. This is especially insidious, both bad design, and evil, hard to test.


• Side Effects are the Way to Go Your best bet is to perform a large number of side effect producing operations in your methods. This is especially true for setters. The more non-obvious the side effects better. Peculiar and seemingly irrational side effects are particularly helpful for unit testing. To add another layer of sweet creamy goodness on top, you want to make it possible to initialize your objects in an invalid state, with uninitialized member fields. Once you have achieved this, be sure to make calls on the methods of the uninitialized fields as side effects from your setters in order to cause SEGV's or NPE's, depending on your language's vernacular. Why go to all this trouble? Clean, readable, and testable code that works, that's why! Side effect free functions are for intellectual weaklings that think a function name should give some kind of an indication of what the function does.


• Create Utility Classes and Functions/Methods - For instance, you have a String which is a URL you're passing around (obeying "Use Primitives Wherever Possible"). Create another class with static methods such as isValidUrl(String url). Don't let the OO police tell you to make that a method on a URL object. And if your static utility methods can call to external services as well, that's even better!


• Create Managers and Controllers - all over the place have these Managers and Controllers meddling in the responsibilities of other objects. Don't bother trying to pull that responsibility into other individual objects. Look at a SomeObjectManager class and you have no idea what it's going to do.


• Do Complicated Creation Work in Objects - Whenever someone suggests you to use a Factory to instantiate things, know that you are smarter than them. You're more intelligent than they must be, because your objects can have multiple responsibilities and be thousands of lines long.


• Greenlight if-branches and switch statements - Go ahead, don't feel dirty about nesting if-branches. It's "more readable" that way. OO cowboys will want to have a whole polymorphic soup of collaborating objects. Say no to the OO-ist. When you nest and branch conditionals, all you need to do is read the code from top to bottom. Like a great novel, one simple linear prose of code. With the OO-overboard paradigm, it's like a terrible choose-your-own-adventure kid's book. You're constantly flipping between classes and juggling patterns and so many more complex concepts. Just if-things out and you'll be fine.


• Utils, Utils, Utils! - Code smell? No way - code perfume! Litter about as many util and helper classes as you wish. These folks are helpful, and when you stick them off somewhere, someone else can use them too. That's code reuse, and good for everyone, right? Be forewarned, the OO-police will say that functionality belongs in some object, as that object's responsibility. Forget it, you're way to pragmatic to break things down like they want. You've got a product to ship after all!


• Use "Refactoring" whenever you need to get away with something - This is a word that Test-Driven and OO-goons like. So if you want to do something far reaching, involving new functionality, without tests, just tell them you're "Refactoring." It'll trick them every time. No matter that they think you need to have tests around everything before you can refactor, and that it should never add new functionality. Ignore their hubbub, and do things your own way!

Java Specific

• Final Methods - Use final classes and methods all the time. They can't be overridden for testing (-; But don't bother making fields final, or using value objects (without setters) - just let your objects' state be changed by anything and anyone. No sense in guaranteeing state, it'd make things too easy.


• Handcuff your users to Specific Types - Use instanceof as much as possible. This will make Mocking a pain, and show people that you're in control of the objects allowed.

C++ Specific

• Use non-virtual methods - Unless you need to override the method in a deep and scary inheritance hierarchy, just make the method non-virtual. If you make it virtual, a TDD zealot may mock your class! An even nicer trick is to keep your destructor non-virtual - then when the testing freaks try to subclass, whooooaoaaaaaa....


• Never use pure abstract classes - Depending on pure abstract classes is a sure-fire way to let the TDD crazies inject stubs and mocks into your code, making it testable.


• Macros are your friends - Always use #ifdef PROD and other compile-time switches to make sure the testies can't get at your really important blocks of code and test them. In fact, this code won't even run: until it gets to production!

by Miško Hevery Every time I see Law of Demeter violation I imagine a haystack where the code is desperately trying to locate the needle.

class Mechanic {
Engine engine;
Mechanic(Context context) {
  this.engine = context.getEngine();
}
}

The Mechanic does not care for the Context. You can tell because Mechanic does not store the reference to Context. Instead the Mechanic traverses the Context and looks for what it really needs, the Engine. So what is wrong with code like this you say? The problems with such code are very subtle:

• Most applications tend to have some sort of Context object which is the kitchen sink and which can get you just about any other object in the system aka the service locator.
• If you want to reuse this code in a different project, the compiler will not only need Mechanic and Engine but also the Context. But Context is the kitchen sink of your application. It tends to reference to just about every other class in your system, hence the compiler will need those classes too. This kind of code is not very reusable.
• Even if you don't plan to reuse the code, the Context has high coupling with the rest of the system. Coupling is transitive, this means Mechanic inherits all of the badness through association.
• Your JavaDoc is not very useful! Yes, by examining the API I can see that the Mechanic needs Context, but Context is the kitchen sink. What does the mechanic really need? (If you don't have source code nearby, it may be hard to figure out).

But here is the real killer! Writing tests for such code base sucks!

• Every time I have to write a test I have to create a graph of objects (the haystack) which no one really needs or cares for, and into this haystack I have to carefully place the needles (the real object of interests) so that the code under test can go and look for them. I have to create the Context just so when I construct the Mechanic it can reach in the Context and get what it realy needs, the Engine. But context is never something which is easy to create. Since context is a kitchen sink which knows just about everything else, its constructor is usually scary. So most of the time I can't even instantiate Mechanic, not to mention run any tests on it. The testing game is over before it even started.
• Ok, but today we have fancy tools such as JMock and EasyMock, surely i can mock out Context. Yes, you can! BUT: (1) typical setup of a mock is about 5 lines of code. So your test will contain a lot of junk which will mask the real purpose of the test. (2) These tests will be fragile. Every time you refactor something in context, or how context interacts, you are running the risk of breaking your tests. (False negatives) (3) What if you want to test the class Shop which needs a reference to Mechanic? Well then you have to mock out Context again. This mocking tax will be spread all over your tests. In the end the mocking setup will drown out your tests and make for one unreadable test base.

Please stop looking for the needle in the haystack and just ask for the things you directly need in your code. You will thank me later...

class Mechanic {
Engine engine;
Mechanic(Engine engine) {
  this.engine = engine;
}
}

PS: Now imagine how hard will it be to write a test for this class:

class Monitor {
SparkPlug sparkPlug;
Monitor(Context context) {
  this.sparkPlug = context.
        getCar().getEngine().
        getPiston().getSparkPlug();
}
}

GOOD LUCK!

Posted by Patrick Copeland, Engineering Productivity Director

A smart person once said that, "all computer science problems can be solved by introducing another abstraction layer." From a testing perspective, every new abstraction layer also introduces every problem in computer science.

Frank Cohen, of PushToTest, wrote a blog post recently that focuses on the Google Web Tool Kit and puts the challange of dealing new abstration layers into a brief historical perspective.

http://tinyurl.com/6r34jf

Posted by Lydia Ash, Test Engineering Manager

Call for Attendance
Google Test Automation Conference 2008
Seattle, WA
October 23 - 24

Google's Test Automation Conference is built on our participants each bringing their experience, ideas, and insight to the discussions we host. Our participants are all experienced industry professionals working as software development engineers or software testing engineers. For the limited number of spaces available in each year's conference, we ask each applicant to share what they would bring to the discussions as an active participant in the conference.

To apply for a participant space at the GTAC 2008 conference, you can apply:

http://services.google.com/events/gtac2008

Timeline

• Deadline for applying as a participant: August 15
• Notification of acceptance: August 29
• Wait list callbacks: October 3
• GTAC 2008 Conference: October 23 and 24

Scheduled Presentations

• Atom Publishing Protocol, Testing a Server Implementation by David Calavera
• JInjector: a Coverage and End-To-End Testing Framework for J2ME and RIM by Julian Harty, Olivier Gaillard, and Michael Sama
• Advances in Automated Software Testing Technologies by Elfriede Dustin
• Taming the Beast: How to test an AJAX Application by Markus Clermont and John Thomas
• Automated Model-Based Testing of Web Applications by Oluwaseun Akinmade and Prof. Atif M Memon
• Boosting Your Testing Productivity with Groovy by Andres Almiray
• Practicing Testability in the Real World by Vishal Chowdhary
• The New Genomics: Software Development at Petabyte Scale by Matt Wood
• The Value of Small Tests by Christopher Semturs
• Deployment and Test Automation: Extending the Notion of 'Done' to 'System Tested on a Production Deployment' by Marc-Elian Begin

No Registration Fees
The GTAC conference has no registration fees. Once invitations have been sent to participate, full registration instructions will be sent to each invitee. Breakfast and lunch will be provided each day of the conference, as well as a reception the evening of October 23.

Cancellation
If you register as a participant and will not be able to attend, please send email immediately to gtac@google.com to allow a wait list person the opportunity to participate in that slot.

Hotel Accommodations
W Seattle (Conference Venue)
1112 Fourth Avenue
Seattle, WA 98101
(206) 264-6000

Other Hotels in the Area
Hotel Vintage Park
1100 5th Ave
Seattle, WA
(206) 624-8000

Madison Renaissance Hotel
515 Madison St
Seattle, WA
(206) 583-0300

Hotel Monaco
1101 4th Avenue
Seattle, WA
(206) 621-1770

By Miško Hevery

• Unit Testing as the name implies asks you to test a Class (Unit) in isolation.


• If your code mixes Object Construction with Logic you will never be able to achieve isolation.


• In order to unit-test you need to separate object graph construction from the application logic into two different classes


• The end goal is to have either: classes with logic OR classes with "new" operators.

Unit-Testing as the name implies is testing of a Unit (most likely a Class) in isolation. Suppose you have a class House. In your JUnit test-case you simply instantiate the class House, set it to a particular state, call the method you want to test  and then assert that the class' final state is what you would expect. Simple stuff really...



class House {

  private boolean isLocked;



  private boolean isLocked() {

    return isLocked;

  }



  private boolean lock() {

    isLocked = true;

  }

}



If you look at House closely you will realize that this class is a leaf of your application. By leaf I mean that it is the end of the dependency graph, it does not reference any other classes. As such all leafs of any code base are easy to test, because the dependency graph ends with the leaf. But testing classes which are not leafs can be a problem because we may not be able to instantiate the class in isolation.



class House {

  private final Kitchen kitchen = new Kitchen();

  private boolean isLocked;



  private boolean isLocked() {

    return isLocked;

  }



  private boolean lock() {

    kitchen.lock();

    isLocked = true;

  }

}



In this updated version of House it is not possible to instantiate House without the Kitchen. The reason for this is that the new operator of Kitchen is embedded within the House logic and there is nothing we can do in a test to prevent the Kitchen from getting instantiated. We say that we are mixing the concern of application instantiation with concern of application logic. In order to achieve true unit testing we need to instantiate real House with a fake Kitchen so that we can unit-test the House in isolation.



class House {

  private final Kitchen kitchen;
  private boolean isLocked;




   public House(Kitchen kitchen) {

    this.kitchen = kitchen;

  }




  private boolean isLocked() {


    return isLocked;


  }





  private boolean lock() {

    kitchen.lock();

    isLocked = true;

  }


}



Notice how we have removed the new operator from the application logic. This makes testing easy. To test we simply new-up a real House and use a mocking framework to create a fake Kitchen. This way we can still test House in isolation even if it is not a leaf of an application graph.



But where have the new operators gone? Well, we need a factory object which is responsible for instantiating the whole object graph of the application. An example of what such an object may look like is below. Notice how all of the new operators from your applications migrate here.





class ApplicationBuilder {

  House build() {

    return new House(

             new Kitchen(new Sink(), new Dishwasher(), new Refrigerator())

           );

  }

}



As a result your main method simply asks the ApplicationBuilder to construct the object graph for you application and then fires of the application by calling a method which does work.



class Main {

  public static void(String...args) {

    House house = new ApplicationBuilder().build();

    house.lock();

  }

}



Asking for your dependencies instead of constructing them withing the application logic is called "Dependency Injection" and is nothing new in the unit-testing world. But the reason why Dependency Injection is so important is that within unit-tests you want to test a small subset of your application. The requirement is that you can construct that small subset of the application independently of the whole system. If you mix application logic with graph construction (the new operator) unit-testing becomes impossible for anything but the leaf nodes in your application. Without Dependency Injection the only kind of testing you can do is scenario-testing, where you instantiate the whole application and than pretend to be the user in some automated way.

Because the Google C++ Testing Framework was opensourced last week, there will be episodes focusing on it published here in the future. Watch for them. I've reshuffled the schedule to get one out this week.

Google C++ Testing Framework supports two families of assertions with the same interface:

• ASSERT: Fails fast, aborting the current function.
• EXPECT: Continues after the failure.

As Moka the code monkey has shown Uni the testing robot, EXPECT is often more appropriate because it: reveals more failures in a single run, and allows more to be fixed in a single edit/compile/run-tests cycle. Example:

TEST(WordStemmerTest, StemsPluralSuffixes) {
  EXPECT_STREQ("jump", stemmer->Stem("jumps"));
  EXPECT_STREQ("pixi", stemmer->Stem("pixies"));
  EXPECT_STREQ("prioriti", stemmer->Stem("priorities"));
  // etc ...
}

Use ASSERT when it doesn't make sense to continue. Example:

TEST(FileGeneratorTest, CreatesFileContainingSequenceOfChars) {
  ASSERT_TRUE(fp = fopen(path, "r"))
        << "Failed to open " << path;
  ASSERT_EQ(10, fread(buffer, 1, 10, fp))
        << "File " << path << " is too small";
  buffer[10] = '\0';
  EXPECT_STREQ("123456789", buffer)
        << "File " << path << " is corrupted";
}

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

Posted by Zhanyong Wan, Software Engineer

We all know the importance of writing automated tests to cover our code. To make it easier for everyone to write good C++ tests, today we have open-sourced Google C++ Testing Framework (Google Test for short), a library that thousands of Googlers have been using in our C++ programs. Highlights of the project include:

• Google Test is portable: it works on a variety of platforms (Linux, Windows, Mac OS X, and more), with several versions of GCC and MSVC compilers, and with or without exceptions. You can even use it in embedded systems like Windows CE and Symbian. Build tools and test runners for many of these are under active development, with Linux Autotools support already in place.
  
• It supports both fatal and nonfatal assertions. The test will continue after a nonfatal failure. This allows more problems to be uncovered and fixed in a single edit-compile-test cycle.
• It provides many assertions for common testing needs, and lets you easily define new assertions for less common cases.
• On Linux, you can write death tests to ensure that your code crashes with expected errors.
• Because it's based on the popular xUnit architecture, Google Test is easy to learn if you've used any testing framework in this family before.

It will take you about 10 minutes to learn the basics and get started. Stay tuned to this blog for helpful Google Test information in upcoming Testing on the Toilet episodes.

Please send questions and feedback to googletestframework@googlegroups.com (the Google Test Discussion Group). See you there!