Scripting Games are in more or less middle. They have been huge success this year – much more scripts that last year, which is awesome! I was hoping I will be able to grade every script submitted, but at the moment it looks like mission impossible…
Anyway one thing that I would like to highlight today is testing. Seen many entries where single typo made huge difference, including turning 5/4* script into 1* script. And because with PowerShell we got huge power, and with power comes responsibility – testing is more important than ever.
New shiny toy! Broken!?
Imagine you just bought great new shiny toy. Depending on your interests: it can be new title on XBOX that you were looking for. Or new image processing program. Or script editor. You name it. You start it, your hands are shaking and… boom!
Unexpected token ‘)’ in expression or statement.
Feel that frustration? But let go further. It kind of works, but suddenly your computer turns black and everything stops. Next day you open your… search engine of choice to look for the problem and see people that had the same issue. You know, somebody forgot to take off some code that was there to clean one partition. Sadly – it was C:. Oops? Developer had OS on D: and…We are sorry? Terribly Sorry? Hello…?
They test, why can’t you?
Companies that live from developing and selling software test it. Don’t have the numbers, but suspect testing is comparable amount of work and resources as developing is. Microsoft probably tests Word for things like: if it doesn’t start to smell differently if it’s open for too long.
Obviously, when you write simple script there is no need to test very long. But you should do a bare minimum: make sure it works, make sure that parameter work as you expect them to. And what is also important: test any component you’ve added to you script. Have GUI? Test how it behaves. Have help included? Run get-help against your function/ script, make sure help displays and all information is included.
But that’s not enough! Also: make sure your script does what it suppose to! Read requirement carefully, not all of them will be mentioned in design points! If you add all bells and whistles but fail to do the job – don’t be surprised to get 1* grade. Coming back to our Word example: imagine word would have Wingding font hardcoded, without option to change it, no option to copy stuff from it. And would work with speech recognition, read your mind and would record your dreams when you are asleep. Perfect tool? Not really, right?
Few last word on comment based help…
PowerShell version 2 added great functionality: comment based help. With minimal work you can add help to your function or script. It would be fair to say probably that writing help for functions is easier than writing it for cmdlet… But it has some limitations to it. Remember – it’s a key to test it because it may look fine, but minor typo in a keyword – and you are doomed. Your great help suddenly turns into yet another comment. Pretty lengthy and helpful for reviewer, not so for user.
Two years ago I had some issues, and because I have tendency to forget things and make typos everywhere – I wrote myself a function to test-help for functions I was creating. It’s not best tool on Earth and I should probably rewrite it, but it should help you find your sensitive spot when you help will fail to work as expected. But you know, you won’t find out that it fails unless you test…
OK, now for testing procedure I would suggest. It requires only three steps from you, third one is probably optional.
First – run your code where you are developing it. I won’t convince you to one script editor or the other – you choose your tools. But whenever you change things – test it. That means you really shouldn’t change anything just before you submit your code – making changes in online form is always asking for trouble…
Second step – start powershell.exe –noprofile. If you have v3 installed and even if you assume you are not depending on it in your code – include –version 2 parameter. Really, you would be surprised how many tiny things were changed/ improved in v3 that can cause your code to work here – but maybe not there, on judges PC. Now you are free from modules, variables and other handy tools that your script may depend on without you even realizing it.
Last step – just in case – run it on another computer. Preferably one with clean OS without any tools added. Maybe virtual machine? If it works there, it will probably work everywhere.
Scripting Games are only iceberg peak
Remember – I mentioned all that in context of Scripting Games. But it does not mean you should stop test your code once this event is due. If you ever plan to publish your code – really, include testing in your development cycle. It doubles the work, but triples satisfaction. Not only on your side, but mainly on side of your future users. And remember: your future user includes yourself in few months. So even if you write for your own good – test. It’s just simple as that. Power equals responsibility. Powerful tool – damaging/ critical outcomes of mistakes. You can mitigate them with testing and keep both power, and peaceful dreams.