pytrin wrote:Says me. I've worked with it extensively on several recent projects, and some API versions do not act exactly as the manually specifies they should. A part of the problem is obvious difference between the sandbox behavior and the live server (a known problem with paypal)
That's unfortunate, but still doesn't imply the live API is going to change from one day to the next? Why the bleep would they do that? Paypal CEO: "Sales aren't hurting enough so let's randomize the API so no one can query it"
I'm not sure how you're suggesting to write tests to cases that are not known to me.
The current behavior of your class under an edge case is the only unknown. You should know about the edge cases before you begin programming. For certain things, there are 10 edge cases to every 1 specification. Other times there are 100 edge cases to 1 specification. You should know what you're dealing with, and what could go wrong (user trying to hack you through inputs, buffer overflows, negative numbers, strings when expecting numbers, network timeouts, network cable is unplugged, etc..). I know APIs validate their inputs really well and return certain error codes. Each error code is another edge case.
For example when parsing 2digit and 4digit years, the edge cases in approximate order they should be tested are:
- a blank string
- a non numeric string
- mixed numbers & strings
-1 digit years
-2 digit years but its "00" (test that we keep it as a string and not integer cast it)
- 3 digit numbers,
- 5 digit numbers
Once these tests cases are out of the way, *then* you should have the happy path:
- 2 digit years
- 4 digit years
I'll write the happy paths first from time to time, but I never consider the component "done" until I have a good amount of edge cases surrounding it. What's going to happen if your routes between paypal and your server go down? Are you going to be showing the users a PHP error? A stack trace? A friendly error message? How do you know for sure?
Another example, I had to make something replace " " or "-" with "[ -]" (regex for dash or space). So anywhere they had a dash or a space, I wanted rows that had
either dashes or spaces in those spots. I forgot the edge case for someone using "(" and ")" which are regex characters themselves, so when I introduced regex without testing edge cases, I introduced a regression that definitely changed the behavior of other features.
Code: Select all
$value = preg_replace('#[ -]#','[ -]',$value);
The original implementation with a regression now introduced ^
New implementation with edge cases covered:
Code: Select all
$value = str_replace(array('-','*'), array('##hyphen##','##dash##'), $value);
$value = preg_quote($value);
$value = str_replace(array('##hyphen##','##dash##'), array('-','*'), $value);
$value = preg_replace('#\*#','.*',$value);
$value = preg_replace('#[ -]#','[ -]',$value);