Testing on the Toilet

June 12, 2008

Friends you can depend on When you want to test code that depends on something that is too difficult or slow to use in a test environment, swap in a test double for the dependency. A Dummy passes bogus input values around to satisfy an API. Item item = new Item(ITEM_NAME); ShoppingCart cart = new ShoppingCart(); cart.add(item, QUANTITY); assertEquals(QUANTITY, cart.getItem(ITEM_NAME));

A Stub overrides the real object and returns hard-coded values. Testing with stubs only is state-based testing; you exercise the system and then assert that the system is in an expected state. ItemPricer pricer = new ItemPricer(){ public BigDecimal getPrice(String name){ return PRICE; }}; ShoppingCart cart = new ShoppingCart(pricer); cart.add(dummyItem, QUANTITY); assertEquals(QUANTITY*PRICE, cart.getCost(ITEM_NAME));

A Mock can return values, but it also cares about the way its methods are called (“strict mocks” care about the order of method calls, whereas “lenient mocks” do not.) Testing with mocks is interaction-based testing; you set expectations on the mock, and the mock verifies the expectations as it is exercised. This example uses JMock to generate the mock (EasyMock is similar): Mockery context = new Mockery(); final ItemPricer pricer = context.mock(ItemPricer.class); context.checking(new Expectations(){{one(pricer).getPrice(ITEM_NAME); will(returnValue(PRICE));}}); ShoppingCart cart = new ShoppingCart(pricer); cart.add(dummyItem, QUANTITY); cart.getCost(ITEM_NAME); context.assertIsSatisfied();

A Spy serves the same purpose as a mock: returning values and recording calls to its methods. However, tests with spies are state-based rather than interaction-based, so the tests look more like stub style tests. TransactionLog log = new TransactionLogSpy(); ShoppingCart cart = new ShoppingCart(log); cart.add(dummyItem, QUANTITY); assertEquals(1, logSpy.getNumberOfTransactionsLogged()); assertEquals(QUANTITY*PRICE, log.getTransactionSubTotal(1));

A Fake swaps out a real implementation with a simpler, fake implementation. The classic example is implementing an in-memory database, or using a fake BigTable. Repository repo = new InMemoryRepository(); ShoppingCart cart = new ShoppingCart(repo); cart.add(dummyItem, QUANTITY); assertEquals(1, repo.getTransactions(cart).Count); assertEquals(QUANTITY, repo.getById(cart.id()).getQuantity(ITEM_NAME));

While this episode used Java for its examples, all of the above “friends” certainly exist in C++, Python, JavaScript, and probably in YOUR favorite language as well.

More information, discussion, and archives: http://googletesting.blogspot.com Copyright © 2007 Google, Inc. Licensed under a Creative Commons Attribution–ShareAlike 2.5 License (http://creativecommons.org/licenses/by-sa/2.5/).

Public Friends You Can Depend On.odt - NeoOffice ... Code

Jun 12, 2008 - A Stub overrides the real object and returns hard-coded values. Testing with ... implementing an in-memory database, or using a fake BigTable.

180KB Sizes 0 Downloads 161 Views

Recommend Documents

Public Friends You Can Depend On.odt - NeoOffice Writer
Jun 12, 2008 - More information, discussion, and archives: http://googletesting.blogspot.com. Copyright © 2007 Google, Inc. Licensed under a Creative ...

public_static_cling - NeoOffice Writer Code
Jun 26, 2008 - "always throws an exception," "only returns a TheirEntity if the id is a prime," and so forth. These kinds of tests would've been impossible before this refactoring. More information, discussion, and archives: http://googletesting.blog

TimeIsRandom.odt - NeoOffice Writer Code
3 Apr 2008 - There are two barriers to effectively testing this method: 1. There is no easy way to test corner cases; you're at the mercy of the system clock to supply input conditions. 2. When nextMinuteFromNow() returns, the time has changed. This

too_many_tests - NeoOffice Writer Code
Testing on the Toilet. Feb. 21, 2008. Too Many Notes Tests. In the movie Amadeus, the Austrian Emperor criticizes Mozart's music as having “too many notes.” How many small tests are “too many” to test one function? Consider the method decide:

too_many_tests - NeoOffice Writer Code
Testing on the Toilet. Feb. 21, 2008. Too Many Notes Tests. In the movie Amadeus, the Austrian Emperor criticizes Mozart's music as having “too many notes.” How many small tests are “too many” to test one function? Consider the method decide:

TotT-StroopEffect - NeoOffice Writer Code
Feb 7, 2008 - RED, GREEN, BLUE, ... (Try it now!) 2. ...say all 25 colors out loud: GREEN, YELLOW, WHITE... (Try it now!) Did the second task require more time and effort? If so, you're experiencing the Stroop Effect, which roughly says that when a l

testng-on-the-toilet - NeoOffice Writer Code
20 Mar 2008 - TestNG is a test framework for Java unit tests that offers additional power and ease of use over JUnit. Some of TestNG's features will help you to write your PirateShip tests in such a way that you'll be well prepared to take on the Adm

testng-on-the-toilet - NeoOffice Writer Code
Mar 20, 2008 - TestNG's capacity for running tests in parallel. You can do this in the definition of ... in an XML file) with the parallel and thread-count attributes.

public_file_flakiness - NeoOffice Writer
Apr 17, 2008 - The callers of CreateGapLease can continue invoking it as usual, but the unit test can pass in a different path: def testCreateGapLease(self):.

public_file_flakiness - NeoOffice Writer
Apr 17, 2008 - In this case, clearing the file at the start of the test can reduce its brittleness: def testCreateGapLease(self): if os.path.exists(lease_file):. RemoveFile(lease_file) ... Unfortunately, this doesn't completely eliminate the flakines