Skip to main content
added 281 characters in body
Source Link
Vishal Aggarwal
  • 5.6k
  • 2
  • 20
  • 37

Background:JavaScript based automation frameworksJavaScript based automation frameworks heavily depends on asynchronous execution asynchronous execution, promisespromises, callbackscallbacks, anonymous functions, etc which are inherently complex and probably an overkill for a straight forward task like UI test automation where we identify objects based on some locators and perform operations.

Problem Statement: why should we choose JavaScript as a language for UI test automation considering it's fundamental asynchronous nature? What are the trade-offs of choosing it as a language for test automation?

Disclaimer: I have designed a couple of large automation frameworks using the protractor for multiple applications, but I want to understand the trade-off of choosing JavaScript as a language for UI test automation?

Note: I raised this question initially on Stack Overflow but as did not get much response so thought of this might be a better platform as focused on QA only.

Other Similar Questions: Also I have seen other close question(as remarked by Peter),but I think that question is based on the premise where we already have large test base in python/other language but I am taking one more step back where we even don't have any tests in any language.Should we even then consider JavaScript as a language for UI test automation in first place considering its inherent complexity and quirkiness for straight forward task like UI automation???

Background:JavaScript based automation frameworks heavily depends on asynchronous execution, promises, callbacks, anonymous functions, etc which are inherently complex and probably an overkill for a straight forward task like UI test automation where we identify objects based on some locators and perform operations.

Problem Statement: why should we choose JavaScript as a language for UI test automation considering it's fundamental asynchronous nature? What are the trade-offs of choosing it as a language for test automation?

Disclaimer: I have designed a couple of large automation frameworks using the protractor for multiple applications, but I want to understand the trade-off of choosing JavaScript as a language for UI test automation?

Note: I raised this question initially on Stack Overflow but as did not get much response so thought of this might be a better platform as focused on QA only.

Other Similar Questions: Also I have seen other close question(as remarked by Peter),but I think that question is based on the premise where we already have large test base in python/other language but I am taking one more step back where we even don't have any tests in any language.Should we even then consider JavaScript as a language for UI test automation in first place considering its inherent complexity and quirkiness for straight forward task like UI automation???

Background:JavaScript based automation frameworks heavily depends on asynchronous execution, promises, callbacks, anonymous functions, etc which are inherently complex and probably an overkill for a straight forward task like UI test automation where we identify objects based on some locators and perform operations.

Problem Statement: why should we choose JavaScript as a language for UI test automation considering it's fundamental asynchronous nature? What are the trade-offs of choosing it as a language for test automation?

Disclaimer: I have designed a couple of large automation frameworks using the protractor for multiple applications, but I want to understand the trade-off of choosing JavaScript as a language for UI test automation?

Note: I raised this question initially on Stack Overflow but as did not get much response so thought of this might be a better platform as focused on QA only.

Other Similar Questions: Also I have seen other close question(as remarked by Peter),but I think that question is based on the premise where we already have large test base in python/other language but I am taking one more step back where we even don't have any tests in any language.Should we even then consider JavaScript as a language for UI test automation in first place considering its inherent complexity and quirkiness for straight forward task like UI automation???

deleted 58 characters in body
Source Link
Vishal Aggarwal
  • 5.6k
  • 2
  • 20
  • 37

Background:JavaScript based automation frameworks heavily depends on asynchronous execution, promises, callbacks, anonymous functions, etc which are inherently complex and probably an overkill for a straight forward task like UI test automation where we identify objects based on some locators and perform operations.

Problem Statement:why why should we choose JavaScript as a language for UI test automation considering it's fundamental asynchronous nature? What are the trade-offs of choosing it as a language for test automation?

Disclaimer:I am not against JavaScript or its automation frameworks in fact I have designed a couple of large automation frameworksframeworks using the protractor for multiple applications, but I want to understand the trade-off of choosing JavaScript as a language for UI test automation?

Note: I raised this question initially on stackStack Overflow but as did not get much response so thought of this might be a better platform as focused on QA only.

Other Similar Questions: Also I have seen other close question(as remarked by Peter),but I think that question is based on the premise where we already have large test base in python/other language but I am taking one more step back where we even don't have any tests in any language.Should we even then consider JavaScript as a language for UI test automation in first place considering its inherent complexity and quirkiness for straight forward task like UI automation???

Background:JavaScript based automation frameworks heavily depends on asynchronous execution, promises, callbacks, anonymous functions, etc which are inherently complex and probably an overkill for a straight forward task like UI test automation where we identify objects based on some locators and perform operations.

Problem Statement:why should we choose JavaScript as a language for UI test automation considering it's fundamental asynchronous nature? What are the trade-offs of choosing it as a language for test automation?

Disclaimer:I am not against JavaScript or its automation frameworks in fact I have designed couple of large automation frameworks using protractor for multiple applications, but I want to understand the trade-off of choosing JavaScript as a language for UI test automation?

Note: I raised this question initially on stack Overflow but as did not get much response so thought of this might be a better platform as focused on QA only.

Other Similar Questions: Also I have seen other close question(as remarked by Peter),but I think that question is based on the premise where we already have large test base in python/other language but I am taking one more step back where we even don't have any tests in any language.Should we even then consider JavaScript as a language for UI test automation in first place considering its inherent complexity and quirkiness for straight forward task like UI automation???

Background:JavaScript based automation frameworks heavily depends on asynchronous execution, promises, callbacks, anonymous functions, etc which are inherently complex and probably an overkill for a straight forward task like UI test automation where we identify objects based on some locators and perform operations.

Problem Statement: why should we choose JavaScript as a language for UI test automation considering it's fundamental asynchronous nature? What are the trade-offs of choosing it as a language for test automation?

Disclaimer: I have designed a couple of large automation frameworks using the protractor for multiple applications, but I want to understand the trade-off of choosing JavaScript as a language for UI test automation?

Note: I raised this question initially on Stack Overflow but as did not get much response so thought of this might be a better platform as focused on QA only.

Other Similar Questions: Also I have seen other close question(as remarked by Peter),but I think that question is based on the premise where we already have large test base in python/other language but I am taking one more step back where we even don't have any tests in any language.Should we even then consider JavaScript as a language for UI test automation in first place considering its inherent complexity and quirkiness for straight forward task like UI automation???

deleted 425 characters in body; added 73 characters in body
Source Link
Vishal Aggarwal
  • 5.6k
  • 2
  • 20
  • 37

Background:JavaScript based automation frameworks heavily depends on its features such as asynchronous asynchronous execution, promises, callbacks, anonymous functions, etc which are inherently complex and probably an overkill for a straight forward task like UI test automation where we simply identify objects based on some locators and perform operations.

Problem Statement:If we can handle AngularJS/Angular other front-end web application framework pages in non JavaScript based automation frameworks then whywhy should we choose JavaScript as a language for UI test automation considering it's fundamental asynchronous nature?

Alternatives:Or may be use porting of frameworks like protractor in languages like ruby/python which What are simple,readable , user friendly so better suitablethe trade-offs of choosing it as a language for UI test automation task? Is there something inherent in JavaScript which is required in these frameworks?

Disclaimer:I am not against JavaScript or its automation frameworks like Protractor in fact I have designed couple of large frameworksautomation frameworks using protractor for multiple applications, but I want to understand the trade-off of choosing JavaScript as a language for UI test automation?

Note: I raised this question initially on stack Overflow but as did not get much response so thought of this might be a better platform as focused on QA only.

Other Similar Questions: Also I have seen other close question(as remarked by Peter),but I think that question is based on the premise where we already have large test base in python/other language but I am taking one more step back where we even don't have any tests in any language.Should we even then consider JavaScript as a language for UI test automation in first place considering its inherent complexity and quirkiness for straight forward task like UI automation???

Background:JavaScript based automation frameworks heavily depends on its features such as asynchronous execution, promises, callbacks, anonymous functions, etc which are inherently complex and probably an overkill for a straight forward task like UI test automation where we simply identify objects based on some locators and perform operations.

Problem Statement:If we can handle AngularJS/Angular other front-end web application framework pages in non JavaScript based automation frameworks then why should we choose JavaScript as a language for UI test automation considering it's asynchronous nature?

Alternatives:Or may be use porting of frameworks like protractor in languages like ruby/python which are simple,readable , user friendly so better suitable for UI test automation task? Is there something inherent in JavaScript which is required in these frameworks?

Disclaimer:I am not against JavaScript or its automation frameworks like Protractor in fact I have designed couple of large frameworks using protractor for multiple applications, but I want to understand the trade-off of choosing JavaScript as a language for UI test automation?

Note: I raised this question initially on stack Overflow but as did not get much response so thought of this might be a better platform as focused on QA only.

Other Similar Questions: Also I have seen other close question(as remarked by Peter),but I think that question is based on the premise where we already have large test base in python/other language but I am taking one more step back where we even don't have any tests in any language.Should we even then consider JavaScript as a language for UI test automation in first place considering its inherent complexity and quirkiness for straight forward task like UI automation???

Background:JavaScript based automation frameworks heavily depends on asynchronous execution, promises, callbacks, anonymous functions, etc which are inherently complex and probably an overkill for a straight forward task like UI test automation where we identify objects based on some locators and perform operations.

Problem Statement:why should we choose JavaScript as a language for UI test automation considering it's fundamental asynchronous nature? What are the trade-offs of choosing it as a language for test automation?

Disclaimer:I am not against JavaScript or its automation frameworks in fact I have designed couple of large automation frameworks using protractor for multiple applications, but I want to understand the trade-off of choosing JavaScript as a language for UI test automation?

Note: I raised this question initially on stack Overflow but as did not get much response so thought of this might be a better platform as focused on QA only.

Other Similar Questions: Also I have seen other close question(as remarked by Peter),but I think that question is based on the premise where we already have large test base in python/other language but I am taking one more step back where we even don't have any tests in any language.Should we even then consider JavaScript as a language for UI test automation in first place considering its inherent complexity and quirkiness for straight forward task like UI automation???

added 48 characters in body; deleted 31 characters in body
Source Link
Vishal Aggarwal
  • 5.6k
  • 2
  • 20
  • 37
Loading
added 98 characters in body
Source Link
Vishal Aggarwal
  • 5.6k
  • 2
  • 20
  • 37
Loading
added 94 characters in body
Source Link
Vishal Aggarwal
  • 5.6k
  • 2
  • 20
  • 37
Loading
edited tags; edited title
Link
Vishal Aggarwal
  • 5.6k
  • 2
  • 20
  • 37
Loading
Bumped by Community user
Bumped by Community user
Bumped by Community user
Tweeted twitter.com/StackSQA/status/826279885043810305
added 452 characters in body
Source Link
Vishal Aggarwal
  • 5.6k
  • 2
  • 20
  • 37
Loading
Source Link
Vishal Aggarwal
  • 5.6k
  • 2
  • 20
  • 37
Loading