1 / 12

Test patterns

Explore three common test patterns: Crash Test Dummy, Log.String, and Mock objects. Learn how to fake error situations, manage method call sequences, and test expensive resources efficiently. Discover a solution for accessing private fields using reflection.

stevenbryan
Download Presentation

Test patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Test patterns

  2. Test patterns • There are several situations testers face often for which established solutions exist • We will discuss three of these test patterns • Crash Test Dummy • Log String • Mock objects

  3. Crash Test Dummy • Most software systems contain a large amount of error handling code • Sometimes, it is quite hard to create the situation that will cause the error • Example: Error creating a file because the file system is full • Solution: Fake it!

  4. import java.io.File; import java.io.IOException; class FullFile extends File { public FullFile(String path) { super(path); } publicboolean createNewFile() throws IOException { thrownew IOException(); } }

  5. publicvoid testFileSystemFull() { File f = new FullFile("foo"); try { saveAs(f); fail(); } catch (IOException e) {} }

  6. publicvoid testFileSystemFull() { File f = new FullFile("foo") { publicboolean createNewFile() throws IOException { thrownew IOException(); } }; try { saveAs(f); fail(); } catch (IOException e) {} }

  7. Log String • Often one needs to test that the sequence in which methods are called is correct • Solution: Have each method append to a log string when it is called • Then, assert that the log string is the correct one • Requires changes to the implementation

  8. Mock Objects • How do you test an expensive or complicated resource? • Databases take a long time to start • Solution: Have a mock object that acts like a database Database db = new MockDatabase(); db.query("select ...."); db.result("Fake Result");

  9. Mock objects • If the MockDatabase does not get the query it expects, it throws an exception • If the query is correct, it returns the provided result • Caveat: the mock object needs to behave exactly like the real one • Need to have tests for the mock object that are run less frequently

  10. Accessing private fields • Object-oriented design guidelines often designate that certain fields should be private / protected • This can be a problem for testing since a tester may need to assert certain conditions about private fields • Making these fields public defeats the purpose

  11. A solution • Using reflection, one can actually call private methods and access private attributes! • An example class A { private String sayHello(String name) { return"Hello, " + name; } }

  12. import java.lang.reflect.Method; publicvoid testPrivateMethod { A test = new A(); Method[] methods = test.getClass().getDeclaredMethods(); for (int i = 0; i < methods.length; ++i) { if (methods[i].getName().equals("sayHello")) { Object params[] = {"Ross"}; methods[i].setAccessible(true); Object ret = methods[i].invoke(test, params); System.out.println(ret); } } }

More Related