



Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Exercise 6.7. Yes, it is possible to use the same appointment object at different times within a single day. The tests are not as legitimate anymore, ...
Typology: Exercises
1 / 5
This page cannot be seen from the preview
Don't miss anything!




Exercise 6. It should be good enough to check just a few of the possibilities. It would be wise to check the boundaries as well as at least one non-boundary value. Examples of times to test: 9, 13, 17 Exercise 6. Yes, it is possible to use the same appointment object at different times within a single day. The tests are not as legitimate anymore, because we can no longer see the difference between the objects (because there is none) and therefore we can't be sure that the appointments are in the correct time slots. It would make sense to use the same appointment object if you have a recurring appointment. For instance you might have a daily meeting with someone. Exercise 6. Several of the tests will fail. makeAppointment only uses the starting time of an appointment to check if the slot is free, and it can therefore overwrite other appointments or exceed the boundary (which results in an exception). For instance, try booking a two-hour appointment at 1700 or one at 0900 when the 1000 time is already booked. Exercise 6. Positive Negative 6.1 X 6.2 X 6.3 X 6.4 X 6.5 X 6.6 X Other negative tests:
The regression test we have done so far still requires manual inspection of the output. This would be very hard and time consuming to do if we had many hundreds or thousands of tests. The difficulty means that, in practice, manual checking will not be done thoroughly, which calls into question the value of the testing. Exercise 6. A test class initially contains the methods: The constructor setUp() tearDown() Exercise 6.
This could have a big impact on subsequent calls. This is most likely the source of the inconsistent result we saw in exercise 6.22. Exercise 6. Two things has come to our attention while doing the walk through:
The result should be 6, which is indeed what is in the displayValue at the end of the walk through. Exercise 6. Yes. The output shows the same information as we collected in the table in the previous exercises. Exercise 6. Debug statements have to be removed again. Debug statements might be less error prone than the manual walk through. Debug statements might be easier/faster to do (this is probably subjective) Debug statements are easier to use when you need to verify a correction. The activity of doing the manual walk through might give a better understanding of the program. Exercise 6. See the project from the cd: calculator-full-solution Exercise 6. The bugs in the bricks project are: class Brick: getSurfaceArea(): side1 should be side2 in sum getWeight(): 1000 should be 1000. class Palette: getHeight(): % should be * getWeight(): + baseWeight is missing