Unit testing and scaffolding
7 likes5,688 views
This document provides an extensive overview of unit testing and testing scaffolding within software engineering, focusing on various testing methodologies such as unit testing, integration testing, functional testing, and the use of frameworks like JUnit 4.x. It explains the significance of these testing types and techniques, including the principles of testing in isolation using mocks and stubs, and emphasizes the importance of constructing reliable units in software development. Additionally, it addresses best practices, challenges, and references for further reading on testing patterns and methodologies.
Unit testing and scaffolding
- 1. Unit Testing and Scaffolding Course of Software Engineering II A.A. 2010/2011 Valerio Maggio, PhD Student Prof. Sergio Di Martino
- 2. Testing Preliminaries 2 ► You're a programmer ○ a coder, a developer, or maybe a hacker! ► As such, it's almost impossible that you haven't had to sit down with a program that you were sure was ready for use ○ or worse yet, a program you knew was not ready ► So, you put together a bunch of test to prove the correctness of your code ○ Let's think about what correctness means
- 3. Testing Preliminaries 3 ► Correctness in Testing ? ○ Which is the point of view ? ► Different points of view means different types of tests (testing) ► Automated tools support
- 4. Outline 4 ► Testing Taxonomy ○ Brief Introduction ► Unit testing with JUnit 4.x ○ Main differences with JUnit 3.x ○ Backward compatibilities ○ JUnit Examples in practice ► Test Scaffolding and Mocking
- 5. 1. Types of testing 5
- 6. Example Scenario 6 ► (… not properly related to Computer Science :) ► Please, imagine that you have to test a building ○ Test if it has been constructed properly ○ Test if it is able to resist to earthquake ○ …. ► What types of “testing” will you do? ○ Make an educated guess
- 7. Five Types of Testing 7
- 8. Unit Testing 8 ► Testing of the smallest pieces of a program ○ Individual functions or methods ► Keyword: Unit ○ (def) Something is a unit if it there's no meaningful way to divide it up further ► Buzz Word: ○ Testing in isolation
- 9. Unit Testing (cont.) 9 ► Unit test are used to test a single unit in isolation ○ Verifying that it works as expected ○ No matter the rest of the program would do ► Possible advantages ? ○ (Possibly) No inheritance of bugs of mistakes from made elsewhere ○ Narrow down on the actual problem
- 10. Unit Testing (cont.) 10 ► Is it enough ? ○ No, by itself, but... ► … it is the foundation upon which everything is based! ► (Back to the example) ○ You can't build a house without solid materials. ○ You can't build a program without units that works as expected.
- 11. Integration Testing 11 ► Aim: Push further back boundaries of isolation ► Tests encompass interactions between related units ► (Important) Every test should still run in isolation ○ To avoid inheriting problems from outside ► Tests check whether the tested unit behave correctly as a group
- 12. Functional Testing 12 ► a.k.a. System Testing ► Extends boundaries of isolation even further ○ To the point they don't even exist. ► Testing application Use Cases ► System tests are very useful, but not so useful without Unit and Integration tests ○ You have to be sure of the pieces before you can be sure of the whole.
- 13. Stress and Acceptance Testing 13 ► Stress/Load Testing ○ Test of loadings and performances ● (Non functional requirements) ○ Test if the building is able to resist to the earthquake ► Acceptance Testing ○ Last but not least.... ○ … does the customer get what he or she expected?
- 14. Before going on... ►Let's take a look at this code, please 14
- 15. 2. JUnit Testing Framework 15
- 16. Junit 3.x Design 16 ► Design that is compliant with xUnit framework guidelines
- 17. JUnit Assertions 17 ► assertNotNull ○ Test passes if Object is not null. ► assertNull ○ Test passes if Object is null. ► assertEquals ○ Asserts equality of two values ► assertTrue ○ Test passes if condition is True ► assertFalse ○ Test passes if condition is False ► assertSame ○ Test passes if the two Objects are not the same Object
- 18. JUnit 4.x Design 18 ► Main features inspired from other Java Unit Testing Frameworks ○ TestNG ► Test Method Annotations ○ Requires Java5+ instead of Java 1.2+ ► Main Method Annotations ○ @Before, @After ○ @Test, @Ignore ○ @SuiteClasses, @RunWith
- 19. Java5 Annotations at glance 19 ► Meta Data Tagging ○ java.lang.annotation ○ java.lang.annotation.ElementType ● FIELD ● METHOD ● CLASS ●… ► Target ○ Specify to which ElementType is applied ► Retention ○ Specify how long annotation should be available
- 20. JUnit Test Annotation 20
- 21. Testing exception handling 21 ►Test anything that could possibly fail
- 22. New way of Testing exception handling 22 ►Test anything that could possibly fail
- 23. JUnit 4.x backward compatibility ► JUnit provides a façade class which 23 operates with any of the test runners. ○ org.junit.runner.JUnitCore
- 24. JUnit Matchers: Hamcrest 24 ► Junit 4.4+ introduces matchers ○ Imported from Hamcrest project ○ http://code.google.com/p/hamcrest/ ► Matchers improve testing code refactoring ○ Writing more and more tests assertion became hard to read ○ Remember: ● Documentation purposes ► Let's do an example …
- 25. Matchers Example 25
- 26. JUnit 4.x Extensions 26
- 27. 3. Testing Scaffolding Programming today is a race between software engineers striving to build bigger and better idiot- proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Cit. Rich Cook 27
- 28. Integration Testing Example public class TestDB extends TestCase { 28 private Connection dbConn; protected void setUp() { dbConn = new Connection( "oracle", 1521, "fred", "foobar"); dbConn.connect(); } protected void tearDown() { dbConn.disconnect(); dbConn = null; } public void testAccountAccess() { // Uses dbConn xxx xxx xxxxxx xxx xxxxxxxxx; } }
- 29. Integration testing problem 29 ► Integrate multiple components implies to decide in which order classes and subsystems should be integrated and tested ► CITO Problem ○ Class Integration Testing Order Problem ► Solution: ○ Topological sort of dependency graph
- 30. Integration testing example 30
- 31. Testing in isolation 31 ► Testing in isolation offers strong benefits ○ Test code that have not been written ○ Test only a single method (behavior) without side effects from other objects ► Focused Integration Testing (!!) ► Solutions ? ○ Stubs ○ Mocks ○…
- 32. Testing in Isolation: example 32
- 33. Solution with stubs 33
- 34. Solution with Mocks 34
- 35. Key Ideas 35 (Ignoring the specifics of codes) ► Mocks do not provide our own implementation of the components we'd like to swap in ► Main Difference: ○ Mocks test behavior and interactions between components ○ Stubs replace heavyweight process that are not relevant to a particular test with simple implementations
- 36. Naming Problems and Buzz Worlds 36 ► Unfortunately, while two components are quite distinct, they're used interchangeably. ○ Example: spring-mock package ► If we want to be stricter in terms of naming, stub objects defined previously are ○ test doubles ► Test Doubles, Stubs, Mocks, Fake Objects… how can we work it out ?
- 37. Test Double Pattern (a.k.a. Imposter) 37 ►Q: How can we verify logic independently when code it depends on is unusable? ○ Q1: How we can avoid slow tests ? ►A: We replace a component on which the SUT depends with a “test-specific equivalent.”
- 38. Test Stub Pattern 38 ►Q: How can we verify logic independently when it depends on indirect inputs from other software components ? ►A: We replace a real objects with a test-specific object that feeds the desired inputs into the SUT
- 39. Mocks Objects 39 ►Q: How can we implement Behavior Verification for indirect outputs of the SUT ? ►A: We replace an object on which the SUT depends on with a test-specific object that verifies it is being used correctly by the SUT.
- 40. Mock Objects Observations 40 ► Powerful way to implement Behavior Verification ○ while avoiding Test Code Duplication between similar tests. ► It works by delegating the job of verifying the indirect outputs of the SUT entirely to a Test Double. ► Important Note: Design for Mockability ○ Dependency Injection Pattern
- 41. Design for Mockability 41 ► Dependency Injection
- 42. Design for Mockability 42 ► Q: How much are the directions in which we could slice functionalities of the system under test? ► A: ○ Vertical Slicing ○ Horizontal Slicing ►
- 43. Mock Libraries 43 ► Two main design philosphy: ○ DSL Libraries ○ Record/Replay Models Libraries ► Record Replay Frameworks ○ First train mocks and then verify expectations ► DSL Frameworks ○ Domain Specific Languages ○ Specifications embedded in “Java” Code
- 44. Mocking with EasyMock 44
- 45. EasyMock Test 45 ► Create Mock objects ○ Java Reflections API ► Record Expectation ○ expect methods ► Invoke Primary Test ○ replay method ► Verify Expectation ○ verify method
- 46. JMock Example 46
- 47. JMock features 47 ► JMock syntax relies heavily on chained method calls ○ Sometimes difficult to decipher and debbuger ► Common Pattern: invocation-count (mockobject).method(arguments); inSequence(sequence-name); when(state-machine.is(state-name)); will(action); then(state-machine.is(new-state name));
- 49. JMock features (intro) 49 ► JMock previsous versions required subclassing ○ Not so smart in testing ○ Now directly integrated with Junit4 ○ JMock tests requires more typing ► JMock API is extensible
- 50. JMock Example 50
- 51. 1. Test Fixture 51 ► Mockery represents the context ○ Neighboring objects it will communicate with ○ By convention the mockery is stored in an istance variable named context ► @RunWith(JMock.class) annotation ► JUnit4Mockery reports expectation failures as JUnit4 test failures
- 52. 2. Create Mock Objects 52 ► The tests has two mock turtles ○ The first is a field in the test class ○ The second is local to the test ► References (fields and Vars) have to be final ○ Accessible from Anonymous Expectations ► The second mock has a specified name ○ JMock enforces usage of names except for the first (default) ○ This makes failures reporting more clear
- 53. 3. Tests with Expectations 53 ► A test sets up it expectations in one or more expectation blocks ○ An expectation block can contain any number of expectations ○ Expectation blocks can be interleaved with calls to the code under test.
- 54. 3. Tests with Expectations 54 ► Expectations have the following structure: invocation-count (mockobject).method(arguments); inSequence(sequence-name); when(state-machine.is(state-name)); will(action); then(state-machine.is(new-state name));
- 55. What's with the double braces? 55 context.checking(new Expectations(){{ oneOf(turtle).turn(45); }}); ► Anonymous subclass of Expectations ► Baroque structure to provide a scope for building up expectations ○ Collection of expectation components ○ Is an example of Builder Pattern ○ Improves code completion
- 56. What's with the double braces? 56 context.checking(new Expectations(){{ oneOf(turtle).turn(45); }});
- 57. Allowances and Expectations 57 context.checking(new Expectations(){{ ignoring (turtle2); allowing (turtle).flashLEDs(); oneOf(turtle).turn(45); }}); ► Expectations describe the interactions that are essential to the protocol we're testing ► Allowances support the interaction we're testing ○ ignoring() clause says that we don't care about messages sent to turtle2 ○ allowing() clause matches any call to flashLEDs of turtle
- 58. Allowances and Expectations 58 context.checking(new Expectations(){{ ignoring (turtle2); allowing (turtle).flashLEDs(); oneOf(turtle).turn(45); }}); ► Distintion between allowances and expectations is not rigid ► Rule of Thumb: ○ Allow queries; Expect Commands ► Why? ○ Commands could have side effects; ○ Queries don't change the world.
- 59. Dependency injection issues? ► Too Many Dependencies ○ Ideas?? 59
- 60. Dependency injection issues? ► Dependency injection for mockability 60
- 61. Expectations or … ? ► Too Many Expectations ○ Ideas?? 61
- 62. Expectations or … ? ► Too Many Expectations ○ Ideas?? 62
- 63. Expectations or … ? ► Too Many Expectations ○ Ideas?? 63
- 64. Development process 64 ► Let's think about the development process of this example: Test ?? Code Test Refactoring ► Q: Does make sense to write tests before writing production code? ► A: Two Keywords ○ TDD: Test Driven Development ○ Test-first Programming
- 65. Mocks and Stubs Pitfall 65 ► False sense of security ► Maintenance Overhead ○ Keep mocks up2date with test and producton code ○ Example: ● UserManager won't send mail no more ○ Maintenance headaches in making test code to run
- 66. References 66 ► Professional Java JDK 5 Edition ○ Richardson et. al., Wrox Publications 2006 ► xUnit Test Patterns ○ G. Meszaros, Addison Wesley 2006 ► Next Generation Java Testing ○ Beust, Suleiman, Addison Wesley 2007 ► JUnit in Action, 2nd Ed. ○ Massol et al. , Manning Pubs 2009 ► Python Testing ○ Arbuckle Daniel, Packt Publising 2010