Wednesday, January 31, 2007

Where are the developer-testers and tester-developers?

Posted by Harry Robinson, Software Engineer in Test

On Saturday, February 24, the Mountain View Googleplex will offer hospitality, support and free munchies for the first-ever "Developer-Tester/Tester-Developer Summit" -- a peer-driven gathering of developer-testers and tester-developers from around the industry to share knowledge and code.

The Summit is being organized by Elisabeth Hendrickson of Quality Tree Software and Chris McMahon of Lyris Technologies, who describe the day this way:

Our emphasis will be on good coding practices for testing, and good testing practices for automation. That might include topics like: test code and patterns; refactoring test code; creating abstract layers; programmatically analyzing/verifying large amounts of data; achieving repeatability with random tests; OO model-based tests; creating domain specific languages; writing test fixtures or harnesses; and/or automatically generating large amounts of test data.

Check out this post at Test Obsessed to learn more about the inspiration behind DT/TD and how you can participate.

Wednesday, January 24, 2007

TotT: Better Stubbing in Python

So you've learned all about method stubs, mock objects, and fakes. You might be tempted to stub out slow or I/O-dependent built-ins. For example:

def Foo(path):
if os.path.exists(path):
return DoSomething()
return DoSomethingElse()

def testFoo(self): # Somewhere in your unit test class
old_exists = os.path.exists
os.path.exists = lambda x: True
self.assertEqual(Foo('bar'), something)
os.path.exists = lambda x: False
self.assertEqual(Foo('bar'), something_else)
# Remember to clean-up after yourself!
os.path.exists = old_exists

Congratulations, you just achieved 100% coverage! Unfortunately, you might find that this test fails in strange ways. For example, given the following DoSomethingElse which checks the existence of a different file:

def DoSomethingElse():
assert os.path.exists(some_other_file)
return some_other_file

Foo will now throw an exception in its second invocation because os.path.exists returns False so the assertion fails.

You could avoid this problem by stubbing or mocking out DoSomethingElse, but the task might be daunting in a real-life situation. Instead, it is safer and faster to parameterize the built-in:

def Foo(path, path_checker=os.path.exists):
if path_checker(path):
return DoSomething()
return DoSomethingElse()

def testFoo(self):
self.assertEqual(Foo('bar', lambda x: True), something)
self.assertEqual(Foo('bar', lambda x: False), something_else)

Remember to download this episode of Testing on the Toilet, print it, and flyer your office.

Tuesday, January 23, 2007

Welcome to the Google Testing Blog

Posted by Allen Hutchison, Engineering Manager

I work in the Test Engineering team, and have always been passionate about sharing my test experiences with others. Last year we organized the first Google Test Automation Conference, where about 150 people from the testing community got together at our London office for two days to talk about testing. One of the great bits of feedback that we heard was that people were very interested in our experiences with testing at Google. We decided to start this blog to share our experiences with the rest of the developer community, and so that we can learn about some of your smart solutions to the same sorts of problems.

From unit testing to performance testing and beyond, the testing umbrella is vast, and hopefully this blog will be the start of a great conversation about these important issues. Whether you're already deeply immersed in the world of testing or just starting to get your feet wet, we hope that this blog will help spread our enthusiasm about testing and help you to write better code. We don't have all the answers, but we have gained a lot of experience and we are anxious to share it with you! So please keep reading, and do send us your comments.

Sunday, January 21, 2007

Introducing "Testing on the Toilet"

We want you to write more tests. Yes, you. You've already been told that tests are the safety net that protects you when you need to refactor your code, or when another developer adds features. You even know that tests can help with the design of your code.

But, although you've read the books and heard the lectures, maybe you need a little more inspiration, tips, and prodding. And you need it to be in a place where when you see it, you can't ignore it.

That's where we can help. We're the "Google Testing Grouplet," a small band of volunteers who are passionate about software testing.

We're unveiling the public release of "Testing on the Toilet": one of Google's little secrets that has helped us to inspire our developers to write well-tested code. We write flyers about everything from dependency injection to code coverage, and then regularly plaster the bathrooms all over Google with each episode, almost 500 stalls worldwide. We've received a lot of feedback about it. Some favorable ("This is great because I'm always forgetting to bring my copy of Linux Nerd 2000 to the bathroom!") and some not ("I'm trying to use the bathroom, can you folks please just LEAVE ME ALONE?"). Even the Washington Post noticed.

We've decided to share this secret weapon with the rest of the world to help spread our passion for testing, and to provide a fun and easy way for you to educate yourself and the rest of your company about these important tricks and techniques.

We'll be putting episodes on this blog on a regular basis and providing PDFs so you can print them out and put them up in your own bathrooms, hallways, kitchens, moon bases, secret underground fortresses, billionaire founders' Priuses, wherever. Send your photos and stories to and let us know how Testing on the Toilet is received at your company.

And meanwhile, keep writing those tests.