I ended my last post saying that I’d coded all I could and now needed to understand the business functionality a little better so I could call pretty much any method of my choice. Note that this is primarily for the functions which need parameters; so logically it includes any create/update/delete function. When I discussed this with Dinis, he suggested I first write a few unit tests for some web service methods. Now I’ll be frank here, I don’t hide the fact that I’m not some ace developer. In fact I’ve never had a formal programming job..ever. I can understand and write code reasonably well but its all self taught and I have never ever written a “unit test” for code. Error handlers yes. Unit tests? So I now had to go and read about what Unit Tests were and why they were really needed. After doing that, this is how I can best explain them.
It’s best to look at it from a developer’s perspective. I write a piece of code, which has 10 functions. All of that together is my program. Later some one else modifies my program to add functionality. Now they don’t want to change all 10 functions; but want to say edit functions 6 and 7. So they need to first know though, that functions 1-5 work properly. So they write 5 unit tests for the first 5 functions. If each unit test succeeds, they know each function works and can focus on the new stuff. Its a nice way of testing bits of code, little by little and eventually build up to the whole program. So to sum up really..and I took this from Wikipedia I think…”Unit testing provides a sort of living documentation of the system. Developers looking to learn what functionality is provided by a unit and how to use it can look at the unit tests to gain a basic understanding of the unit’s API. ”
So once I write those 5 unit tests, each of those 5 have a result; as in they will return SOME value. Right or Wrong. The unit test has something called an Assert statement, which compares the result of the function output to the correct expected value. It then ‘fails’ if it isn’t a match. So..very simply…the results of the functions 1-5 above are all assertions. For example we would write an assertion as follows: assert(Login(valid username, valid password)) == 32 bit GUID. So now..if a 32 bit GUID isn’t returned, although we supplied a valid user name and password we say that the assertion has failed, and there is something wrong in the Login method. What is wrong? That’s something the developer has to explore further. Similarly, assertions will be created for tests 1 to 5 above.
Right..so coming back to our Web service methods again…we need to write unit tests and assertions for every single method here. If all my assertions WORK, then I’m sure that I have understood enough of the Web service to be able to craft requests and retrieve and update data. And NOW i can try and start entering malicious inputs as the values of one or more of the parameters…to check how the application handles any of them. Each one of these ‘BAD’ tests is called an abuse test case.
So to sum it all up..
a) Query the WSDL and get all methods
b) Query each method with its individual parameters wherever needed
c) Note down the exceptions generated
d) Create unit tests, thus ensuring that you’re entering the right values, assuming you’re a valid user
e) Build abuse test cases once all your unit tests have succeeded.
Yep. Makes total sense. So now I’m planning to target the key methods first, all of which are listed here. I’ll come back with my findings and keep you guys up to date with what we’re doing on this front. For the rest, make sure you keep reading Dinis’s blogs :). Cya.