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.