Forum Discussion
Hi,
Below are just my comments. Obviously, test code can be implemented with or without using exceptions. This is a matter of code design and what requirements do you have for test code.
> The call stack in the log should cover what is required for users.
I would say that users do not care about call stack. What they do care is the report about whether or not the tested function works as required. And this must be clear from test log with the clear and understandable description of what exactly did not work (in case of failure). If call stack is required to figure out what or why did not work, for me this means a poor logging. Thus I consider Call Stack feature of TestComplete to be development means.
> I can now use it in two contexts.
-- Nothing prevents you to have three functions: to check if the file is writable; to make file writable and to write to the file. And to call them as your test dictates;
-- Each exception type must be explicitly handled in the calling code, so this does not differ a lot from return code. Generic exception handling is not considered as a good programming practice and is not recommended AFAIK;
-- Exceptions are a good means to either handle unexpected situations (like lost of connectivity) or as a means to report a problem and do not crash the application. But the test, by definition, checks a certain defined behaviour and all deviations must be clearly reported in order to be triaged whether or not they are a real problems. If they are not, then the test code must be enchanced to make these deviations to become possible expected handled behaviour;
-- Exceptions are usually either unrecoverable events (when they are handled at the end of the calling code and do a proper cleanup) or must be handled right after function call to make it possible to retry and/or continue. Considering our example with the read-only file, if the exception is thrown and calling function handles it at the end, the only thing that it can done is to cleanup and report a problem. In almost all cases the current test must be stopped after that (because of unstable environment state) and leave you without any information about whether or not the verified task can be done by the end-user. If the exception (or return code) is handled immediately after the function call, then test code has a chance to make the file writable and retry. As a result, you can get a notification that for some reason the file appeared to be read-only, but the whole functionality remained valid after the file was made writable. I think that this is much more useful result if you need to make a decision about tested application's state but not just report the first problem and stop. (Basically, this is the primary difference between the integration and end-to-end testing and TestComplete really excels with the latter though is perfectly usable for the former.)
Hi AlexKaras
I've opted in the end to go more down the route of building the KWTs themselves with Try.. catches.. in them and having the KWTs return a true/false in the catch/finally depending on how things went. Much less OO, much more scripting approach:
Return false from a Keyword Test
I'm using some work in the OnLogError to help me handle and error things better and report back better info, but the approach is now leaving only application exceptions to technically thow errors. Other errors will be handled with intensive standard wait/find logic, but scripts should always return Something. Either a true/false or an object/null which can be tested and acted upon by the calling function/KWTs. The next KWT in a tree will check the lastresult for a true/false and log/stop as required
Related Content
- 13 years agojitendra_1
- 6 years agosriram_sig
- 10 years agomrezahoseini
- 4 years agobwolsleben
Recent Discussions
- 9 hours agoashly