So I’ve got a lot of Unit tests done and uploaded on to Git. 102 I think.. to be precise. The rest, for some reason are pending..eventually those might be removed, reworked upon or retested. All the same, 102 out of 123 is a reasonably nice achievement :). Once I’d uploaded all my tests though and thought of what to do next..it struck me that the initial authorization script that I’d written, while cool, at that stage wouldn’t scale without a ton of rework on it. Here’s why.
The methods cannot be randomly invoked in any order; well.. some can..but many of them are interdependent on each other. So for example: If I didn’t have ANY libraries in Team Mentor (Don’t ask me why ;)) and tried to invoke DeleteLibrary it would be a flop…as there would be no libraries to delete. So I’d have to invoke CreateLibrary first; create a dummy library and then invoke DeleteLibrary. The initial script linked above, invokes methods randomly from a hash and hence can fail.
The other reason is that the values of the parameters being passed to numerous functions are complex. So for example: If you look at the method CreateArticle, it takes a TeamMentor article object as an argument. Its not just a blank object…any object will have variables that it “contains”..and this is no different. So I’ll have to set article.title = ‘Arsenal FC’ and article.striker=’RVP’ and then send it on as CreateArticle(article). Makes sense? Now… my previous authorization script had discounted all this complexity…and I was reading all the sample values from a file which had sample values for each data type. Like this. So xs:string could be the data type of the argument for 2 methods…but the string value actually passed would HAVE to be different. So the strings passed for say; DeleteFolder(‘United’) and DeleteUser(‘AF’) are different. You can’t just have one string for every single method that has an argument of the xs:string datatype. And sadly, that was precisely what my initial script was doing :(. Poorly designed as it turns out…but then again… hindsight is always a wonderful teacher.
So I had two choices…either sit and hack at that script and make it fit all these new requirements…or just abandon it (Ouch) and do something newer but more effective. And if you’re a starter in programming….like I was a few years back…know this ‘Don’t love your code so much that you can’t let it go’. So I dumped my auth script and decided to use all my unit tests to check across users instead. Here is what I did.
First I ensured that every single unit test had a login as ‘admin’ method, even if it didn’t need one. The Login method takes a username and a hash. Now I made 3 copies of my 102 unit tests in 3 folders: Editor, Reader, Anonymous. See where I’m going with this? Now using the awesome sed , I replaced the credentials for Admin with those for a reader, editor and an anonyomous user(blank). All in separate folders. And if you run py.test from any folder… it automatically seaches for tests in THAT folder and runs all of them. So now.. I could choose to run just ‘get method’ tests for ‘editor’ or .. ‘put’ method tests for ‘reader’ and look at what tests failed or passed. Much more control and dare I say…much cleaner than my 31337 script ;).
Now that I could run 102 tests across 4 categories of users… my next job was to see whether:
a) I could generate a nice report…?
b) Could I make every single test…totally independent ?
Huh? What? independent…aren’t they ALREADY independent…not quite. Wait up for the next blog… which will be up very soon.