Modularity-driven testing: Difference between revisions
m Disambiguating links to Script (help needed) using DisamAssist. |
m Disambiguating links to Programming (link changed to Computer programming) using DisamAssist. |
||
Line 7: | Line 7: | ||
The test [[script]]{{dn|date=February 2018}} modularity [[framework]] requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test. These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case. |
The test [[script]]{{dn|date=February 2018}} modularity [[framework]] requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test. These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case. |
||
Of all the frameworks, this one should be the simplest to grasp and master. It is a well-known [[programming]] strategy to build an abstraction layer in front of a component to hide the component from the rest of the application. This insulates the application from modifications in the component and provides modularity in the application design. The test script modularity framework applies this principle of abstraction or [[encapsulation]] in order to improve the maintainability and scalability of automated test suites. |
Of all the frameworks, this one should be the simplest to grasp and master. It is a well-known [[Computer programming|programming]] strategy to build an abstraction layer in front of a component to hide the component from the rest of the application. This insulates the application from modifications in the component and provides modularity in the application design. The test script modularity framework applies this principle of abstraction or [[encapsulation]] in order to improve the maintainability and scalability of automated test suites. |
||
<ref>{{cite web|last=Kelly|first=Michael|title=Choosing a test automation framework|url=http://www.ibm.com/developerworks/rational/library/591.html|accessdate=2013-02-22}}</ref> |
<ref>{{cite web|last=Kelly|first=Michael|title=Choosing a test automation framework|url=http://www.ibm.com/developerworks/rational/library/591.html|accessdate=2013-02-22}}</ref> |
||
Revision as of 22:13, 18 February 2018
![]() | This article needs more links to other articles to help integrate it into the encyclopedia. (March 2013) |
Modularity-driven testing is a term used in the testing of software.
Test Script Modularity Framework
The test script[disambiguation needed] modularity framework requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test. These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case.
Of all the frameworks, this one should be the simplest to grasp and master. It is a well-known programming strategy to build an abstraction layer in front of a component to hide the component from the rest of the application. This insulates the application from modifications in the component and provides modularity in the application design. The test script modularity framework applies this principle of abstraction or encapsulation in order to improve the maintainability and scalability of automated test suites. [1]
References
- ^ Kelly, Michael. "Choosing a test automation framework". Retrieved 2013-02-22.