well i think if you want to be productive in test automation you will quickly see recurring patterns emerge that you will want to encapsulate to increase productivity. well thats where programmings starts :) you will want to look into concepts like PageObjects to reduce the impacts changes have.

i have years of experience in test automation (even developed a test tool for ui automation myself) and i can tell you, that test automation is essentially software development. you develop software (sometimes with the help of powerful libs) to automate other software. most of the tools provide some capture replay functionality but to be honest capture replay does not work well. its like programming spagetti code ;) what you will want is dev know-how to write scripts/tests in a programming language. i can recommend ranorex as a very versatile tool with a very nice c# api.

hrhrhr it gets better by the post :D pathetic oop vs "real programmers" - mmd

of ocaml is your idea of perfect coding style we have very different views how good codes looks or reads.

gotos are definitly not essential for state machines. there are a number of patters and frameworks that are a better solution than goto hell. if this code has higher level languages as output then i dont believe gotos are required but if the code is not touched by human hands...

and i thought this must be a trolling competition- i mean the goto debate is over for decades now. seriously- there are many arguments against gotos (as already posted in this thread) and i have yet to find problems better solved with goto instead of proper object orientation. ad bad code: working code != good code. that code works is the foremost and basic assumption- good code easily readable, understandable, maintainable and extensible- all things where goto brings nothing to the table- on the contrary it may (and has) severely hinders it...

No. Simple as that. the only reason to use goto is to write bad code :)