search

test-fullautomation / robotframework

Generic automation framework for acceptance testing and RPA
http://robotframework.org
Apache License 2.0
1 stars 0 forks source link

Ugc1hc/feat/threading feature #75

Closed milanac030988 closed 7 months ago

milanac030988 commented 7 months ago

*Fixed issues: https://github.com/test-fullautomation/robotframework/issues/48 https://github.com/test-fullautomation/robotframework/issues/45 https://github.com/test-fullautomation/robotframework/issues/43 https://github.com/test-fullautomation/robotframework/issues/42 https://github.com/test-fullautomation/robotframework/issues/41 https://github.com/test-fullautomation/robotframework/issues/50 https://github.com/test-fullautomation/robotframework/issues/46 https://github.com/test-fullautomation/robotframework/issues/49

milanac030988 commented 7 months ago

Hello Holger,

I'd like to answer your questions regarding to threading document:

  1. The THREAD works as a keyword like FOR, WHILE or TRY, you can call it in a testcase or put it in a User Defined keyword.
  2. The THREAD start as soon as it call, it mean after the line 'THREAD ${ThreadName} ${IsDaemon}'
  3. Different threads has different variables scopes.
  4. I don't want to restrict users from naming threads with duplicate names, even though it's generally not advisable due to the potential for overlapping log files and receiving notifications from other threads, leading to strange behaviors. I prefer to give users more freedom and hold them more accountable for the scripts they write. In certain situations, this flexibility could serve their specific purposes. For example, they might want to send notifications to two specific threads instead of broadcasting to all or just one. Therefore, allowing duplicate thread names could be beneficial in these unique scenarios, despite the inherent risks.
  5. It's case sensitive

Thanks, Cuong

test-fullautomation commented 7 months ago

Hi Holger, I agree to Cuong's answer. Thank you, Thomas