Java Reference
In-Depth Information
From these exercises, it is easy to see how valuable interactive method invocations and inspec-
tors are in giving immediate feedback on the state of an object, often avoiding the need to add
print statements to a class when testing or debugging it.
7.3.2
Positive versus negative testing
When deciding about what to test, we generally distinguish positive and negative test cases.
Positive testing is the testing of functionality that we expect to work. For example, adding a
comment by a new author with a valid rating is a positive test. When testing positive test cases,
we have to convince ourselves that the code did indeed work as expected.
Concept:
Positive testing is
the testing of cases
that are expected
to succeed.
Negative testing is the test of cases that we expect to fail. Using an invalid rating or attempting
to store a second comment from the same author are both negative tests. When testing negative
cases, we expect the program to handle this error in some specified, controlled way.
Concept:
Negative testing
is the testing of
cases that are
expected to fail.
Pitfall It is a very common error for inexperienced testers to conduct only positive tests. Negative
tests—testing that what should go wrong indeed does go wrong, and does so in a well-defined
manner—are crucial for a good test procedure.
Exercise 7.11 Which of the test cases mentioned in the previous exercises are positive
tests and which are negative? Make a table of each category. Can you think of further positive
tests? Can you think of further negative ones?
7.4
Test automation
One reason why thorough testing is often neglected is that it is both a time consuming and a
relatively boring activity if done manually. You will have noticed, if you did all exercises in
the previous section, that testing thoroughly can become tedious very quickly. This particularly
becomes an issue when tests have to be run not just once but possibly many hundreds or thou-
sands of times. Fortunately, there are techniques available that allow us to automate repetitive
testing, and so remove much of the drudgery associated with it. The next section looks at test
automation in the context of regression testing.
7.4.1 Regression testing
It would be nice if we could assume that correcting errors only ever improves the quality of a
program. Sadly, experience shows that it is all too easy to introduce further errors when modi-
fying software. Thus, fixing an error at one spot may introduce another error at the same time.
As a consequence, it is desirable to run regression tests whenever a change is made to software.
Regression testing involves rerunning tests that have previously passed, to ensure that the new
version still passes them. It is much more likely to be performed if it can be automated. One of the
easiest ways to automate regression tests is to write a program that acts as a test rig , or test harness.
 
 
Search WWH ::




Custom Search