scripting - any test procedure?

Hi guys,

im busy creating TCL scripts for a project i have on at university.

Now im wondering is there such a thing as an official process or even best practice on how to test a script and also how to document the test and its results? i would like some guidlines to give me some direction particularly when it comes to the documentation side.

I know this probably sounds like a stupid question but i have no programing/scripting experiance at all, so are unaware if there is such a thing. I have googled but have found nothing so far.

Cheers and thanks for the help.

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

Forsaken_GA

I usually toss in debug code to make sure my script is obtaining the information I expect, and then having it echo it out before I actually make it do anything.

for example -

let's say I'm on a unix box and I have a boatload of directories I want to remove, and I have that list, but I don't want to type out each individual command to do so.

so lets say i have the following in a list called foo.txt:

/home/luser/deleteme1
/home/luser/deleteme2
/home/luser/deleteme3
/home/luser/deleteme4
[..]
/home/luser/deleteme5697

Rather than typing in all 5697 rm -r commands, I'll do the following:

for x in `cat foo.txt`; do echo rm -r $x; done

Instead of actually executing rm -r on every single one of those directory paths, it will instead echo back to me the commands it will actually run out of that loop. This will tell me that it's A) reading my input file correctly and

passing that information along correctly. Once I'm reasonably sure that the loop will do what I want it to do, I'll remove the echo statement and it will run the rm -r command as expected. If the output with the echo command isn't what I expect (for example, lets say I typo'd the input file as foobar.txt, and the only thing in foobar.txt is a single line containing /, I just prevented myself from destroying all data on my machine).

Every single programming or scripting language I've ever encountered has some form of function that will just print the input it's given to the screen, and this is what I've found as the most effective way to test that my logic is correct and the script will do what I expect it to do.

Met44

i would like some guidlines to give me some direction particularly when it comes to the documentation side.

If you want to document the tests, I would suggest basing a write-up for the test off of the steps in the scientific method. University people will like it, and it makes sense.

If you want to document the scripts themselves and how they interact with whatever you are doing, look into creating flowcharts, process diagrams, and/or structured English.

This may seem like overkill depending on how small/big your project is. Regardless, it's a good exercise if you want to learn how to (or are expected to) "do it right."

Forsaken_GA has a good approach to adding debugging instrumentation to your scripts. If you feel your scripts are complicated enough, I would also suggest writing in some sort of "switch" which will let you turn such debugging output on and off. That way, you can write the debug statements as "part" of the code, rather than as an afterthought, and only flip them on when you want to verify something. This will save you time re-writing tests or having to delete/comment them afterward.

HeroPsycho

Met44 wrote: »

If you want to document the scripts themselves and how they interact with whatever you are doing, look into creating flowcharts, process diagrams, and/or structured English.

...

Forsaken_GA has a good approach to adding debugging instrumentation to your scripts. If you feel your scripts are complicated enough, I would also suggest writing in some sort of "switch" which will let you turn such debugging output on and off. That way, you can write the debug statements as "part" of the code, rather than as an afterthought, and only flip them on when you want to verify something. This will save you time re-writing tests or having to delete/comment them afterward.

To Visio document your PowerShell scripts, you can use this:

PowerShell, PowerShell Script Generator, Visio Add In, Visio Download

It actually even helps you code your script, too. Citrix has another workflow product that does something similar, too for PowerShell.

Documenting your scripts in my experience is usually done with comments supported in the scripting language (prefacing a string with # for example in PowerShell) within the script explaining what each thing that's not brain dead obvious what's going on. Also, you should make a boiler plate template to include in the beginning of all your scripts, including the script's name, when you created, who created it, contact info, key words about what the script does, a brief explanation of what it does, and other helpful info.

nel

thanks for the advice guys!