Some unit testing frameworks allow you
to specify a run order, but if you end up doing that a lot you should begin
to wonder why there are so many order dependencies in your tests.
In my examples, we have been creating the fixture objects we need
every time, in every test. This creates a lot of redundancy, and since eliminating
redundancy is a first principle, we know for sure that we would
rather eliminate it if possible.
Luckily, JUnit was invented by people who understand this principle
very well, and so there are two annotations you can assign to methods:
@Before and @After. You can call the methods anything you like, but to
be consistent with other testing tools that dictate the method names, I
like to call them setUp() and tearDown().
Like the testXXXXX() methods, these two must have a void return
type and take no parameters. However, the assurance is that setUp() is
called right before each test method is called, and tearDown() is called
right after. Each time.
So, if I have three test methods??”testOne(), testTwo(), and
testThree()??”the IDE??™s testing mechanism will call
setUp() testOne() tearDown()
setUp() testTwo() tearDown()
setUp() testThree() tearDown()
However, again, the order of the actual test method calls may be different.
Pages:
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313