One of the things I do is implement tax and shipping rules for clients. As an interesting aside, we use a early web services technique invented at Yahoo! where we recieve a POST of all the data and return the results in custom headers. Anyway, as you can expect, it's often a challenge to capture the exact rules required and they tend to be pretty complicated.
I'd just been working on adding rules for AK and HI for a client that only previously shipped to the 48 contiguous states and the added complexity made me worried that I made a mistake. I wanted to write tests, but I wanted something at a higher level than just writing Perl code, and more importantly I wanted a test suite that the client can add to. I came up with the following format:
product: 9848rdc
quantity: 1
options: Size: 148
product: 9852rdc
quantity: 2
options: Size: 152
state: AK
country: US
method: Ground
cost: 24.95
--
product: bk7ma
product: 9848rdc
options: Size: 148
state: AK
cost: 39.95
method: Ground
I then wrote a script that reads this in, turns each section into three tests (using Test::More): we were able to POST, we didn't get back an error, and we got back the right cost. We've now got a format that allows non-programmers to write tests, and they're often the best people to write them because they know what they expect the system to do.
Re:Wiki tests
lachoy on 2004-12-01T20:43:46
Thinking of FIT or Test::FIT? These are nifty, but I have a sneaking suspicion that customers who use such systems are are more willing to learn than the ones I normally deal with.
