Forum Discussion
Hi,
> We are asked to use Python as scripting language [...]
Just a quick note related to Python that personally I got a big problem with. Hopefully, others will comment what I did wrong or how they solve this problem:
The case is that Python does not have any special means (parenthesis, curly braces, etc.) to group script flow instructions (loops, conditions, etc.) and the only means are indents. If, for example, you created initial file in the editor that do not use tabs for indents but only spaces, do later some modifications in the editor that uses tabs for indents and then open the file in the editor that expands tabs to spaces (or treat tabs to equal not to 8 spaces, but to some other number of them), the chances are high that this will break initial indentation of the code and thus can break all code logic (because some lines of code can move in or out of the code flow control statements).
Restore of the initial code logic requires significant efforts because there is no other means except (broken) indentation that defines whether or not the given line of code must be within or outside, say, a loop statement. So, in order to restore the position of the line of code (inside or outside of the flow control operator) one must to get the complete understanding of what the given piece of code was expected to do initially.
Hope, that this my negative experience will be clarified by those who have positive experience with Python.
Hm... I never have had the problem mentioned by AlexKaras.
I have set up the built in code editor of TestComplete in the same way as I have set up all of my other code editors and IDEs (like IDLE, Eclipse and Notepad++). Actually we only need to define the number of indents (spaces) per one block of code.
Also I am always using the source control system to store and update my code in a safe way. It's a kind of insurance for the case if I have broken something anyhow.
=====
MaheshBhoite, first of all you should define your framework architecture. In a very common approach you need to separate your test-steps from the test data, from application mapping and logic and from configuration and infrastructure. In other words your whole test should looks like:
myApp.start()
myApp.login()
myApp.doSomething()
myApp.validateSomething()
myApp.logout()
myApp.stop()
And nothing else.
Definition of all methods like start(), login() etc. should be hidden from your test in the separate module.
All infrastructure configuration like server name, data bases etc. should be hidden from your test in the separate module or inside of config- or ini- files.
All test data like credentials and other input values should be hidden from your test in the separate module, in variables or somewhere else.
All elements mapping should be hidden from your test in the separate module, classes or/and in the NameMapping repository.
...and so on
- Colin_McCrae9 years agoCommunity Hero
I haven't used the TC IDE with Python, but the indentation use is deliberate.
Python is designed to work this way.
https://www.python.org/dev/peps/pep-0008/
It is meant to encourage neat code design. And stop spaghetti code. Which I guess it does as spaghetti code in Python quickly becomes unreadable.
I guess if you REALLY wanted visual separators, you could always just use comments?
- AlexKaras9 years agoChampion Level 3
Hi Colin,
> Python is designed to work this way.
Yes, I know this.
This talk is, actually, out of scope, so quick comment without the intention for the discussion. :)
It is my personal opinion that not bad idea (code visual clarity) was implemented in an average way. The worst thing is that if for some reason (poor web page formatting, different editors, any other reason) original indentation of your code is broken, it is not easy task to restore it (which is equivalent to restore of the code logic). With the majority of other languages (Pascal, C, Java... Even VB) this is a matter of automated formatting.
In addition, personally I had a lot of inconveniences because of this Python feature. The case that I am used to use temporary debug logging. Especially in cases when debugger is not available. (E.g. TestExecute or Python without IDE set up.) To have those temporary debug logging statements to be easily identifiable later, I used to put them at the very beginning of the line. This is fast and makes those temporary lines of code visually quickly identifiable. Obviously, this approach does not work with Python and I had to indent those temporary statements and mark them with some comment to be able to identify them later. (BTW, I don't like automatic formatting in Visual Studio because of the same exact reason.)
Related Content
- 4 years ago
- 2 years ago