Script Testing
 

Hi Guys,

Would anyone like to share their testing procedures. I'm used to programming languages that allow line-by-line, or section, steps - evaluating as the routine progresses. With vB it seems that's not a method that can be used. It's OK vB advising to learn by looking at others' scripts, but there's little that can be gained (?) without a deeper evaluation than appears possible - or am I missing something quite obvious?

Using a PHP or xml tester seems not an option....

warm thanks

Geoff

Most of us have a test/dev site setup.

Generally testing involves giving a script values for whatever post/get/db variables its looking for (both valid and invalid values) and checking to see if I get expected behaviour. Behaviours can be in multiple forms including checking the visible markup (i.e. xhtml, javascript, css) as well as verifying data sent to or received from the db by using manual queries. As noted above this is all done on a test site so as not to pooch a live site.

Thanks guys, though of course having a test site is only one aspect to consider.

Funnily enough some things that don't work on the test site, work on the live (and vice versa).

But some long scripts that involve a lot of actions, how do you keep track? It seems inefficient to play guessing at least some of the time and not to be able to use a good php/xml editor/diagnostic to check.

This usually happens because of hard coded variables, or something which makes the script not be universal (lazy coding, or different strictness settings in PHP)

I use Notepad++ for the coding, and then test on my test sites (one on Windows/IIS and one on Linux/Apache). I have a few scripts with thousands of lines, and have never had an issue doing things this way.

This will usually be caused by the fact that your test site is not identical to your live site, including but not limited to, php version/settings, mysql version/settings, vb version/settings, installed mods verion/settings, data on your live site is different from your test site, and a host of others as well.

You write extra code, that you remove later, which outputs running data either to the screen or to a file on the server which you can review to determine how far you got, or like vbulletin upgrades you have steps and and you output stuff before and after each step to be able to figure out where things went wrong if they do wrong. If doing this last one, make sure each step is small so that figuring what is wrong to fix it only has to look at a few different things. The bigger each step is the more complex it is to debug the step.

Thanks . I use scite as editor, fairly basic but good and simple (like me!)

Obviously the days when one could use a 'record new macro' as a starter are long gone.

--------------- Added [DATE]1452074302[/DATE] at [TIME]1452074302[/TIME] ---------------

One obvious quirk is the Test Site has a "Master Style" and yet the Live one doesn't have one (in view).

Best place then, for a test bed, is on the main server!

:D

--------------- Added [DATE]1452074597[/DATE] at [TIME]1452074597[/TIME] ---------------

One question that keeps bugging me is where to put files on the server. Some are obvious, such as "images"/"admincp" etc - but "includes""clientscripts" ?

[S]Does anyone know of a list of vBulletin variables - and what each one does .... ?[/S] Ah - I can glean something using Firebug DOM :rolleyes: