Hi all,
I would like to know how can i organize eggplant scripts for an application. How the planning should be done to write the scripts for it. Say for example, for a simple calculator application, how should i plan out the scripts in an organized way :?:
This gets to the heart of testing, and there isn’t any one answer that’s going to be right for every company or every situation. In testing, as in many endeavors, there are tradeoffs between what is ideal and what is practical.
For your calculator example, you might decide to create 4 scripts to test addition, subtraction, multiplication, and division. Here’s an example multiplication script that multiplies every pair of numbers in the range 1 to 100:
-- Multiplication.script
repeat with num1 = 1 to 100
repeat with num2 = 1 to 100
TypeText num1
Click "MultiplyButton"
TypeText num2
Click "EqualsButton"
TypeCommand "C" -- copy answer to clipboard
put the remoteClipboard into answer
if answer is not equal to num1 times num2 then
LogError "Wrong Answer: " & answer & " for " & num1 & " * " & num2
end if
end repeat
end repeat
This seems like a nice straightforward approach to testing a calculator, but there are problems here. First of all, it only tests numbers up to 100. There are no really large operands or results being tested. And even at that, it’s going to perform 10,000 operations, multiplying every possible combination of the numbers between 1 and 100, which will take a very long time.
A more useful approach will not test every possible combination, but will try instead to exercise the calculator with a variety of different numbers, and will also pay special attention to what happens in cases that might be “problematic”, such as multiplying by 0, or by a negative number.
To show one way you might go about this with the calculator, let’s first make our script more modular, by separating out the part that chooses the numbers to test from the part that tests a particular multiplication, which we’ll turn into its own script:
-- TestMultiply.script
params num1, num2, expectedAnswer
TypeText num1
Click "MultiplyButton"
TypeText num2
Click "EqualsButton"
TypeCommand "C" -- copy answer to clipboard
put the remoteClipboard into answer
if answer is not equal to expectedAnswer then
LogError "Wrong Answer for " & num1 & " * " & num2 & \
" Expected " & expectedAnswer & " but got " & answer
end if
Now we can call this script from multiple places in our main test. Here’s a script that combines several approaches:
-- Multiplication.script
-- first, test a sampling of values throughout a range
repeat with num1 = -10000 to 5000 stepping by 451
repeat with num2 = -5000 to 10000 stepping by 613
TestMultiply num1, num2, num1*num2
end repeat
end repeat
-- next, test some random numbers
repeat 100 times
-- choose two random integers between -10,000 and 10,000
set num1 to random(-10000,10000)
set num2 to random(-10000,10000)
TestMultiply num1, num2, num1*num2
end repeat
-- finally, try some specific values that may be "problematic"
TestMultiply 0, 10000, 0
TestMultiply 10000, 0, 0
TestMultiply 0, 0, 0
Planning out how to test your application is very important, and will help you decide how to best organize your scripts. I hope the example above at least helps give you some things to think about. Keeping things modular can be very helpful (as done above to separate the main interaction into its own TestMultiply script).
Also think about focusing your testing on the most critical areas of your application, or on things that you think are the most likely to have problems (“high risk” areas of your application), since in any non-trivial application it is never going to be possible to test every possible set of values.
It would be interesting to hear ideas from other Eggplant users about how they go about this. Anyone?