Surely, you have no trouble understanding what is happening in our test method: First, we define two variables for

the expected and the actual number of flights in the internal table IT_Flights, one variable for an instance of the class we want to test and four structures of the line type of IT_Flights. We fill these f our structures, create an instance of the production class we test and add three structures to the internal table by using the method add_flight of this class. In the same manner as in our first example we perform the test in the assert_equ als method. In our example we add a fourth structure to the internal table and t est if the number of lines in the table has increased by one as it should be if the portion of code under test worked properly. Remember that after the modifica tion of the program it is no longer possible to add a flight with the same price as an already existing flight to the internal table. Flight number 4 has the sa me price as flight number 3, and so this flight will not be added to the interna l table. If the assert condition is violated, an error is raised which is shown by the ABAP Unit Tool after the test is run. h3. Still Skeptic about ABAP Unit? Again, the more skeptic-minded among you might not be really convinced. They mig ht suppose a trick: Why did we test by sheer accident just the method which was affected by the side effect with just the right test data? Is this not a very im probable coincidence? As I will show you in the next part of this flash light on ABAP Unit, it is of c ourse not the mere writing of ABAP Unit tests that does the job all by itself. O bviously, tests have to be cleverly devised according to certain principles. Thi s is what I will tell you next time: a little bit of theory on which tests with ABAP Unit should be based.