Java Reference
In-Depth Information
interceptBefore method starts the timer D , and the interceptAfter method
stops it and prints the execution time on the screen E .
Now we need a test case for this interceptor. And here it comes—listing B.7.
Listing B.7
Test case for the timing interceptor
[...]
@RunWith( InterceptorRunner. class )
@InterceptorClasses( SampleTimingInterceptor. class )
public class TestCustomRunnerWithTimingInterceptor {
@Before
public void longSetUp() throws InterruptedException {
Thread.sleep( 1000 );
}
B
C
@Test
public void testDummy() throws InterruptedException {
Thread.sleep( 2000 );
assertTrue( true );
}
D
@After
public void longTearDown() throws InterruptedException {
Thread.sleep( 1000 );
}
}
We take the same approach as we used for the last interceptor test case: declare the
runner we use with the @RunWith annotation B and specify at C which interceptor
classes we use by means of the @InterceptorClasses annotation.
You might be wondering why we need these interceptors; they simply execute some
common logic before/after the tests (the same way the @Before / @After methods do).
The point is that sometimes it's hard to determine how much time is required for a
test method to execute. In our case we have the longSetUp() and longTearDown()
methods (at D ), which also could take a lot of time, thus making it harder to deter-
mine the execution time of the testDummy() method itself. Because our timing
interceptor keeps track of the execution time for the test methods only (the
interceptBefore method is executed after the @Before methods, and intercept-
After is executed before the @After methods), this makes it a perfect candidate to
solve our problem.
Upon executing the test case, we should see something like the following in
the console, despite the fact that the JU nit runner might show a different value
(figure B.1).
Interceptor started.
Interceptor ended. The test executed for 2 sec.
 
 
Search WWH ::




Custom Search