NOTICE: Our Community is moving. Get more information. Updated information on a New Login Process
SilkTest has functions and methods already defined to verify that the actual, on-screen value is exactly what you expect it to be. However, there is nothing built into the 4Test language to make sure that a value in the application under test (AUT) is close enough. For example, in a great number of engineering and scientific applications there"s an acceptable margin of error. That is, "3.8" is considered a right answer if the expected value is "4" and there"s a margin of error of .2. Additionally, verifying if some text that has a date and time stamp in it has the right text except for the date and time.
To verify if a number is close enough, a new function can be used called VerifyNear that closely resembles the Verify function that we all know.
Note the tolerance level to be passed in as defined as number. This will allow both real or integer to be passed in.
The last argument, the description, will be much like the last argument to the Verify function.
To test whether or not the two values, nActual and nExpected are within the acceptable tolerance level, they can just subtract one from the other, get the absolute value of the result, and compare whether or not the difference is less than or equal to the tolerance, nTolerance:
And, if the difference is greater than the tolerance, raise our own error.
The above VerifyNear function works great for verifying that two numerical values are close to one another (or not), but there are also times that string expression may require verified to see if it is close enough (or not). This can be done by pretty much duplicating the functionality of the Verify function, but using wildcards in the expected value for the function.
The VerifyFuzzy function is shown here.
By using the MatchStr function rather than checking for an exact match, calling the VerifyFuzzy function allows for wildcards to be put into the expected value. Wildcards for single characters (?) or multiple characters (*) can be used.
The Hidecalls statement removes the function from the call stack if/when an error occurs inside of that function. So, for example, if VerifyFuzzy raises an error above, double-clicking on the error in the results file will display the line where the function was called rather than the raise statement inside of the function, which is really where the error occurred.