Test Patterns in Java

Transcription

1 Test Patterns in Java Jaroslav Tulach, Jesse Glick, Miloš Kleint Sun Microsystems JavaOne SM Conference Session BOF 0220

2 Automated Testing Test is a Kind of Documentation Learn why to invest in automated testing and let us give you overview of the wildest test patterns that NetBeans project found useful JavaOne SM Conference Session BOF

3 Agenda What is the problem? Why do automated tests help? How to write tests? Questions and Answers 2006 JavaOne SM Conference Session BOF

4 The Quality of an Application quality = implementation specification quality may not be the right term maybe term confidence is better regressions cost too much the "amoeba" model 2006 JavaOne SM Conference Session BOF

5 The Amoeba Model 2006 JavaOne SM Conference Session BOF

6 The Amoeba Model 2006 JavaOne SM Conference Session BOF

7 Why write automated tests? Make sure the code works Things do not get wrong concurrent access garbage collection and finalizers Algorithms and data structures are sane fast and small Mistakes do not reappear race conditions deadlocks 2006 JavaOne SM Conference Session BOF

8 Do tests influence code? methods to verify state ways to prevent asynchronous behavior separation to units using lookup and discovery code against interfaces not implementation Java is not single threaded tests may need cooperation with code openide util/org/openide/util/lookup.html 2006 JavaOne SM Conference Session BOF

9 Test Patterns in Java Testing exception states Hard to invent Easy to copy and use Premise: Test everything 2006 JavaOne SM Conference Session BOF

10 Demo Application Extraordinary Complex and Useless Calculator 2006 JavaOne SM Conference Session BOF

11 Code Against Interfaces define abstract interfaces and lookup implementation: public abstract class DialogDisplayer { public abstract Object notify(javax.swing.joptionpane what); public static DialogDisplayer getdefault() { return Lookup.getDefault().lookup(DialogDisplayer.class); // or in Mustang return java.util.serviceloader.load(dialogdisplayer.class).iterator.next(); real implementation in the application mock object in the test 2006 JavaOne SM Conference Session BOF

12 Setup Testing Environment fill lookup with own mock implementation replace UI with headless displayer public class MyTest extends org.netbeans.nbjunit.nbtestcase { protected void setup() { org.netbeans.nbjunit.mockservices.setservices(mockdialogdisplayer.class); public class MockDialogDisplayer extends DialogDisplayer { public static JOptionPane lastpane; public static Object toreturn; public Object notify(joptionpane p) { lastpane = p; return toreturn; 2006 JavaOne SM Conference Session BOF

13 Memory Leak Tests Memory management is important aspect of amoeba easy to regress hard to describe and verify NbTestCase.assertGC(String, Reference); Cooperates with Insane library class SetupAndGCTest extends NbTestCase { public void testtheycandisappear() { Calculator same = Calculator.create("powerful"); WeakReference ref = new WeakReference(same); same = null; assertgc("caches can be GCed", ref); NetBeans JUnit Extensions JavaOne SM Conference Session BOF

14 Memory Leak Tests II Controlling size of data structures hard to describe and verify NbTestCase.assertSize(String, int, Object); virtual size of data structure trees 8/16/16/24 bytes Based on Insane library How big is an empty string? NetBeans JUnit Extensions Object datastructure = ; assertsize( "Less than 16bytes?", 16, datastructure ); class SizeRegisterFailingTest extends NbTestCase: Calculator calc = Calculator.create("powerful"); Calculator.Register reg = calc.getregisters().get(0); assertsize("register contains one integer field => 16 bytes. Will it fit?", Collections.singleton(reg), 16, new Object[] { calc ); // last array allows to exclude some objects 2006 JavaOne SM Conference Session BOF

15 Speed Test NbTestSuite.speedSuite and linearspeedsuite Size of the test Comparing speed of various algorithms Need to eliminate influence of GC and hotspot protected void setup () { calc.ensureregisterssize(gettestnumber()); list = calc.getregisters(); public void test10() { dotest (); public void test100() { dotest (); public void test1000() { dotest (); public void test10000 () { dotest (); private void dotest () { for (int i = 0; i < 10000; i++) { list.get(size / 2); 2006 JavaOne SM Conference Session BOF

16 Randomized Tests Test for the unknown Hard to test where amoeba does more than expected Use random sequence of operations: int op = random.nextint(); switch (op) { case 0: list.add(new Integer(random.nextInt()); break; case 1: list.removeat(random.nextint(list.size())); break; case... Record the seed for case of failure seed = System.currentTimeMillis(); random = new Random(seed); 2006 JavaOne SM Conference Session BOF

17 Deadlock Test I Deadlocks are biggest contributors of amoeba's shaking no reasonable theory hard to simulate from outside 2006 JavaOne SM Conference Session BOF

18 Foreign Code In Critical Section Deadlock prone code Calling foreign code under lock leads to deadlocks Sometimes hard to prevent private HashSet allcreated = new HashSet(); public synchronized JLabel createlabel() { JLabel l = new JLabel(); allcreated.add(l); return l; java.awt.component grabs AWT tree lock HashSet.add calls Object.equals design.html 2006 JavaOne SM Conference Session BOF

19 Deadlock Test II Regression test Reading thread dumps Reproducing thread locks Need more threads Using time out for the test Block them in the right moment overriding virtual methods introducing artificial hooks 2006 JavaOne SM Conference Session BOF

20 Race Condition Test Similar to deadlock tests Missing thread dump information Need more threads Block them in the right moment overriding virtual methods introducing artificial hooks if (System.getProperty( simulate.race.condition.2 )!= null) { Thread.sleep(500); 2006 JavaOne SM Conference Session BOF

21 The Beauty of Logging Analyze random failures protected Level loglevel() { return Level.FINE; CharSequence msgs = Log.enable( logname, Level.ALL); Natural in source code Logger LOG = Logger.getLogger( logname ); LOG.finest( simulate.race.condition.2 ); Tests can plug their own Handlers class TestHandler extends Handler { public void publish(logrecord r) { if (r.getmessage().equals(( simulate.race.condition.2 )) Thread.sleep(500); 2006 JavaOne SM Conference Session BOF

22 Flow Control using Logging Automatic breakpoints Allows replay of captured log files plugs in own handler blocks and wake the threads up Complexity hidden behind simple NetBeans JUnit API: Log.controlFlow( THREAD: main MSG: simulate.race.* THREAD: second MSG: cause problems ); 2006 JavaOne SM Conference Session BOF

23 Summary Prevent Amoeba from shaking from one side e.g. what is not working Automate testing, its cheaper Treat tests as a complement to documentation Use our test patterns Invent new test patterns 2006 JavaOne SM Conference Session BOF

24 References BOF 2559 Thu 19:30 Gateway 105 Discovery and Dependency Injection Patterns in Modular Architectures TS 6218 Fri 14:30 Gateway 102/103 How to Write APIs That Will Stand the Test of Time download from download from JavaOne SM Conference Session BOF

25 Q&A Jesse Glick Miloš Kleint Jaroslav Tulach 2006 JavaOne SM Conference Session BOF